As it stands, order:random right now is very nice for API calls, but the change from being multi-page to a single page makes it harder to browse lots of posts on a desktop.
Whenever I click to go to the next page, I'm automatically brought to the top of the website. Refreshing doesn't do that, and so I have to scroll all the way up to the top and either refresh manually or click the search bar to research order:random.

So I've got a few proposals to change this:

First off is to drop order:random entirely, and instead use "random:X" to return X number of posts, or simply "random:" to return the default amount (the 50 posts we already get from an order:random search)
Obviously not the best solution as existing APIs will need to update to the new tag.

Second is to continue to use order:random, but by doing so, a seeded value is used. The seed will determine, dynamically, when a page is loaded, which posts are loaded for that page. This seed will persist, from the time of search, to the session ID used, or however would be most reasonable to implement into. Hopefully this doesn't screw too much with how the APIs are handled.

You could try a different trick, but it might not work with all browsers. Instead of reloading tap address bar and hit enter again, that'll load the page as if it were new and should put you back at the top.

If you're on a PC press "POS1" on your keyboard to get directly back to the top.

aversioncapacitor' said:
Second is to continue to use order:random, but by doing so, a seeded value is used. The seed will determine, dynamically, when a page is loaded, which posts are loaded for that page. This seed will persist, from the time of search, to the session ID used, or however would be most reasonable to implement into. Hopefully this doesn't screw too much with how the APIs are handled.

presumably you're suggesting this as a strategy to allow pagination with order:random?
the problem is not how the seed is persisted, the problem is that by its nature, pagination through a random order leads to very expensive database queries.
i'm sure i saw Kira mention earlier there are plans to further investigate this. the fallback suggested was to replace the paginator with a simple 'refresh' button, which would also solve your problem as clicking such a link would reset the scroll position.