11–20 of 52 posts
I'm sure there is exceptions, but in general, the last thing I want my browser to do when i press back, is to start making requests. I expect the requests to have been already made.
The way I've always wished the back button worked is as though I had just opened a new tab (instead of clicking a link/submitting a form), and now I've just closed that tab and once again see the original tab I'd left. I assume this is actually a big reason people use (so many) tabs... the back button doesn't work right! Sigh!
The way I've always wished the back button worked is as though I had just opened a new tab (instead of clicking a link/submitting a form), and now I've just closed that tab and once again see the original tab I'd left. I assume this is actually a big reason people use (so many) tabs... the back button doesn't work right! Sigh!
> Today, the only option for ensuring an XHR request is made when the user re-visits a page via the back button is to (1) add an unload handler then (2) use cache busting. I'm sure there is exceptions, but in general, the last thing I want my browser to do when i press back, is to start making requests. I expect the requests to have been already made.
My daily use case for this is Github Issues. Simple repro: Click an issue, make a change, press back.
Now the list view is out of date and doesn't show my changes. So I have to refresh.
I think a background XHR request is the best approach (until browsers fix this issue for real). On page load: pull latest from server (if network is down, then no-op). If no changes, then don't change. If there are changes then replace inline without a new page reload.
The back button has not changed functionality--it still works as expected on all non-webapp webpages.
From my perspective, I think the author should be asking for browsers to implement a new button that follows his desired "load previous URL" behavior.
usually I'll right-mouse-button click + open in new tab on any link instead of just clicking on it.
Eventually, like garbage collection, I'll stop, go back to the start of the tabs and close a bunch of them, then go back to what i was looking at.
And if I'm on a site that doesn't allow right clicking on a link? well the site had better be important otherwise it's gonna get closed.
For example, if I click through to the http 1.1 spec in the first paragraph, then hit "Back" I see the scrollbar shrink as new content is loaded and uBlock's block count increases as new content loads.
If I scroll to the bottom of the page, click a link, and then click back, I don't even go back to the same spot - I'm at the end of the article and content loads below it...
My expectation as a user, regardless of the spec, is that I should see exactly what I saw when I was just on the page. Render to a bitmap, and when I click "back" display the bitmap. If going back to the page requires any network requests then the page is doing it wrong.
The exception that proves the rule would be streaming content.
> Today, the only option for ensuring an XHR request is made when the user re-visits a page via the back button is to (1) add an unload handler then (2) use cache busting. I'm sure there is exceptions, but in general, the last thing I want my browser to do when i press back, is to start making requests. I expect the requests to have been already made.
The result of this thinking is when I press the back button, I have to refresh the page manually because the data is stale. My daily use case for this is Github Issues. Simple repro: Click an issue, make a change, press back. Now the list view is out of date and doesn't show my changes. So I have to refresh. I think a background XHR request is the best approach (until browsers fix this issue for real). On page load:…
If I click back I want to see what I saw last time. e.g. I might have seen 3 news articles I was interested in, I click though and read the first one. When I click back I want to see the exact same list as before, and be able to read the next article I saw; not new articles that have been written while I was reading the last one.
You can s/news article/github issue/ and my response is the same.