Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browser History (2013)

madhatted.com

Post reply on HN
Print view View original

21–30 of 52 posts

Re: Browser History (2013)

#21

Post by userbinator »

jacquesc wrote: post #14
spotman wrote: post #11

> 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:…

Perhaps the Back button should really be split into Back (cached) and Back (reload), since both of those are equally valid use cases. (Edit: the fact that the parent comment and another sibling comment here currently completely disagree is evidence enough that both options are necessary. I personally want both behaviours, depending on the situation.) No doubt the "UX experts" will complain that it's too complicated for "average users", but we aren't and don't want to be "average users" --- we want a powerful browser UI that lets us control our browsing experience better; that's something that seems to be rare in this age of increasingly dumbed-down UIs.

Re: Browser History (2013)

#22

Post by userbinator »

cmg wrote: post #10
fredleblanc wrote: post #4

Earlier quoted context omitted.

I hate when I go back and things change. I went back for a reason! But I'm also of the school that wants View Source to view the source that was just downloaded, not re-download a new copy of the source.

I've never understood why View Source would do anything but show me the source of the page I'm looking at - not the source of the page as it is "now," which could be seconds, minutes or hours later. If I'm looking at a page, the browser has or could have a copy of the original stream sent from the server, why not just display that?

What browser(s) are you using that have such behaviour? Is this a new "feature" in the very latest versions? I don't think I've ever seen View Source make another request on Chrome, Firefox, IE, or Opera.

Re: Browser History (2013)

#23

Post by rudedogg »

wtbob wrote: post #9
taneq wrote: post #6

Earlier quoted context omitted.

> I don't get what he fails to understand: if the back function obeyed expiration headers, then going back could potentially reload the page, potentially causing a re-GET or even a re-POST. There's already behaviour in place in most (all?) browsers to cover this case, at least for POST. When you go back to a page with had form data attached to the request, they'll ask you whether to re-submit the form. This doesn't h…

Honestly, they shouldn't re-prompt IMHO — they should only do that on a reload — rather, they should just display the page as it was, which is what I expect when I hit back.

It would be interesting to see the analytics for this. I've seen the dialog many times, but can't think of a time I resubmitted the form.

Re: Browser History (2013)

#24

Post by paavokoya »

wtbob wrote: post #9
taneq wrote: post #6

Earlier quoted context omitted.

> I don't get what he fails to understand: if the back function obeyed expiration headers, then going back could potentially reload the page, potentially causing a re-GET or even a re-POST. There's already behaviour in place in most (all?) browsers to cover this case, at least for POST. When you go back to a page with had form data attached to the request, they'll ask you whether to re-submit the form. This doesn't h…

Honestly, they shouldn't re-prompt IMHO — they should only do that on a reload — rather, they should just display the page as it was, which is what I expect when I hit back.

I agree. This would greatly frustrate users on quick-feed news sites and social media who are hoping to find that article or post they were just reading to find it now gone because the sites algorithm marked it as 'read'.

Re: Browser History (2013)

#25

Post by Manishearth »

Note that the behavior described in the post is per spec -- the cache spec is a red herring and doesn't apply here. The web specs override the HTTP spec in various spaces.

The relevant spec is at https://html.spec.whatwg.org/multipage/browsers.html#the-ses...

Note:

> An entry with persisted user state is one that also has user-agent defined state. This specification does not specify what kind of state can be stored.

> User agents may discard the Document objects of entries other than the current entry that are not referenced from any script, reloading the pages afresh when the user or script navigates back to such pages. This specification does not specify when user agents should discard Document objects and when they should cache them.

and from https://html.spec.whatwg.org/multipage/browsers.html#travers...

> If entry no longer holds a Document object, then navigate the browsing context to entry's URL

and

> If entry has a different Document object than the current entry,

> ...

> Make entry's Document object the active document

------

Browsers try to treat the back button as if the user had never left the page. So the XHR requests aren't re-made because the page simply isn't reloaded, it's just made active.

The fact that Chrome says "from cache" might be a bug here, but what the devtools show isn't visible to JS/etc, so this isn't a compatibility issue. AFAICT Chrome and Firefox (and presumably Safari) behave the same here, except from a difference in how the bfcache is invalidated. (chrome seems to invalidate when the domain changes).

I'm not clear why all of this is a problem though. If the page is reloaded, it's reloaded. If it's loaded from the bfcache, it's as if it was never unloaded (almost the same as the user switching a tab and coming back, except of course JS was suspended). Both behaviors seem ... fine for a webapp?

Re: Browser History (2013)

#26

Post by daurnimator »

jimjimjim wrote: post #17

I generally want a back button that rewinds time (server side be damned). 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 impor…

Use middle click (or for those without a middle mouse button on a computer they can't reconfigure, use ctrl/cmd + click)

Re: Browser History (2013)

#27

Post by Pxtl »

jacquesc wrote: post #14
spotman wrote: post #11

> 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:…

The difference is that you can go back and reload to do that with the preserved state model, but there's no way to go back to old state with a back-and-fetch model.

Re: Browser History (2013)

#28

Post by mixonic »

Author here, happy this popped up and to see the HN community thinking through it. A few people have brushed off what I sketched as uninteresting and don't see any issues. I'll try to explain it another way (with three years reflection to help).

Single page applications are now quite popular. Most single page apps use a different definition of "back" than browsers do, and there are times when the two treatments conflict.

Many, or most, use a local in-memory database to keep track of information without going to the server. They update that in-memory store as you make changes. For example you see a list of names: Mary, Robert, John. You click Robert and edit the name to "Rob", the name auto-saves. Then you click "back".

Because single-page apps control "back" when in the SPA, they do what most developers want. They return to a semantically correct page, showing Mary, Rob (just edited), John. Tons of apps do this. This is not what the browser does. The browser, if following the "back" specs, would show the out-of-date names of Mary, Robert, and John.

The theoretical conflict can also become practical. Think through this flow:

* Visit /names

* AJAX for GET /api/names

* See Mary, Robert, John

* Edit Robert's name to Bob, autosave

* AJAX for POST /api/name/4 with the new name Bob

* See Mary, Bob, John

* Click on a link, lets say to Mary's website URL

* Mary's website, new domain, loads.

* ...click back

The SPA loads up, and attempts to GET /api/names. However, the bfcache is at play since the native "back" behavior is running. So the stale API response, with the original names Mary, Robert, John is returned. The list of names on the screen is DIFFERENT than what the user saw after they edited.

Additionally most SPA apps presume AJAX calls return accurate data, however here the names are not the names currently in the database. They are only in the bfcache. You can imagine, with more complex data, ways this can cause complex and unforeseen failures.

This is a very poorly understood corner of JavaScript development even today.

[edit]: formatting

Re: Browser History (2013)

#29

Post by cmg »

userbinator wrote: post #22
cmg wrote: post #10

Earlier quoted context omitted.

I've never understood why View Source would do anything but show me the source of the page I'm looking at - not the source of the page as it is "now," which could be seconds, minutes or hours later. If I'm looking at a page, the browser has or could have a copy of the original stream sent from the server, why not just display that?

What browser(s) are you using that have such behaviour? Is this a new "feature" in the very latest versions? I don't think I've ever seen View Source make another request on Chrome, Firefox, IE, or Opera.

Chrome does.

"Yes, when you "view source", you're really opening a new tab that opens the page again and displays the source rather than renders the page."

https://bugs.chromium.org/p/chromium/issues/detail?id=4650#c...

Re: Browser History (2013)

#30

Post by swiley »

zhoujianfu wrote: post #7

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!

This is how mothra on plan9 works. It's really an underrated browser, it has no tabs because it doesn't need them.
Post reply on HN