Browser History (2013)

109 pointsby mattkahlover 8 years ago

13 comments

wtbobover 8 years ago

I don't get what he doesn't understand: when the user goes back, the browser is supposed to show the document he saw when he left, as it was when he left it (so long as that view hasn't expired out of the browser's cache completely). This is intuitively what a user expects, right?> Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider it portant that users not be presented with error messages or warning messages when they use navigation controls (such as BACK) to view previously fetched resources. Even though sometimes such resources ought not to cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. “once-only” URLs) in order not to suffer the effects of improperly functioning history mechanisms.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.

评论 #12546726 未加载

评论 #12544413 未加载

zhoujianfuover 8 years ago

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!

评论 #12544847 未加载

评论 #12545787 未加载

评论 #12545311 未加载

评论 #12544794 未加载

jimjimjimover 8 years ago

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 important otherwise it's gonna get closed.

评论 #12545131 未加载

评论 #12546673 未加载

panicover 8 years ago

You can use the pageshow event to detect when the browser navigates back in history to a page in the back/forward cache: <a href="https://developer.mozilla.org/en-US/docs/Web/Events/pageshow" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/Events/pageshow</a>More generally, you shouldn't make a "single-page app" unless you really need to. The web is designed for navigating between multiple documents. Browser features like history and bookmarks will work better if you stick to the standard behavior.

spotmanover 8 years ago

> 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.

评论 #12544875 未加载

mixonicover 8 years ago

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 backThe 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

评论 #12546426 未加载

评论 #12545750 未加载

评论 #12549015 未加载

rosstexover 8 years ago

On the desktop, I like having the option to see what a page just looked like, without reloading any data.If I hit the back button, it's usually because something on the previous page caught my attention and I want to find it again. If I want to reload a page, I'll refresh or click on the site logo (in the case of getting to the root of the site).

评论 #12544387 未加载

评论 #12548842 未加载

Manishearthover 8 years ago

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 <a href="https://html.spec.whatwg.org/multipage/browsers.html#the-session-history-of-browsing-contexts" rel="nofollow">https://html.spec.whatwg.org/multipage/browsers.html#the-ses...</a>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 <a href="https://html.spec.whatwg.org/multipage/browsers.html#traverse-the-history" rel="nofollow">https://html.spec.whatwg.org/multipage/browsers.html#travers...</a>> If entry no longer holds a Document object, then navigate the browsing context to entry's URLand> 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?

jlaroccoover 8 years ago

It's hard to take this seriously because the page itself does not work correctly w.r.t. the back button.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.

gayprogrammerover 8 years ago

This isn't an all-or-nothing issue. The author generalizes that developers and users today use browsers/html differently than they did before, but what I'm hearing is actually a new way to use the word/button for "(go) back".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.

eridiusover 8 years ago

This article no longer reflects the behavior of Safari at least as of version 10 (the version that ships with macOS Sierra). In my tests, the second version of the page that attempts to bust the bfcache behaves identically to the first version, i.e. the bfcache is not in fact busted.

rob74over 8 years ago

bendmebackmeanywayyouwantme? That rang a bell... but according to <a href="http://www.azlyrics.com/lyrics/garbage/ithinkimparanoid.html" rel="nofollow">http://www.azlyrics.com/lyrics/garbage/ithinkimparanoid.html</a> it should actually be bendmebreakmeanywayyouneedme ;)

ashitlerferadover 8 years ago

[2013]