User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Currently, any page which changes frequently, such as news sites, portals, blogs/etc with short-lived "feature" spots on their homepage, will be lost to the automatic and unmentioned reload when browsing the session history. When a user attempts to go back to see something they saw earlier in the same tab, they may be unable to find it, and unaware that any past pages were discarded. A combination of multiple tabs, long-lived sessions, unclear memory, and unmentioned reloads can be quite frustrating. Reproducible: Always Steps to Reproduce: Note the content (time stamp) at http://lll.lu/~aknaff/bug-reports/mozillaNoStore/no-store.cgi 2. Follow the "continue" link 3. Hit back, and see different content, but no indication that a reload occurred Actual Results: The page is reloaded, showing updated content rather than the expected historical content, without informing the user that a reload took place. Expected Results: Assuming the historical content is not available, and since there is no way to prevent automatically reloading, there should be some indication to the user that the page is new. The demonstration URL is from bug 160144 comment 148 (more cases are available through http://lll.lu/~aknaff/bug-reports/mozillaNoStore ). I would much prefer to replace the automatically reloading behavior entirely; that was refused in bug 569142 comment 9. Automatically reloading when browsing session history, especially without informing the user, violates RFC 2616 section 13.13 by showing the user something other than "exactly what the user saw at the time when the resource was retrieved" or indicating that what was seen is no longer available. See also bug 288462 about related violations in cases where the historical content is available but is not used, and bug 160144 / bug 451250 about the case of an unavailable historical post result. There are many bugs related to history navigation and reloading, the most thorough list may be bug 569142 comment 14. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 : 13.13 History Lists User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.

When submitting this bug I was thinking of the case where historical content has been discarded prior to navigating to the session history entry, however, if providing notification is easier than fixing bug 288462, it would be preferable to have the notification also occur in cases where the historical content is present in the session history but navigation still triggers a reload.

Personally, I think it would be preferable to never have cases where "historical content is present but navigation triggers a reload" . Indeed, if content is present, why not just show it? And if people are divided over the issue, could we at least have some configuration option to let us, the users, chose? Of course, in cases where historical content is genuinely no longer present, it makes sense to show a warning, but I expect such cases to be few and far between.

ENH?

>ENH? ? I do not think that this is an idea that should be implemented in the core product. You would get an annoying bar/dialog/whatever on manny sites with dynamic content. The back button means for me "bring me back to the URL hat I have previously visted" but not "show me the cintent that I have previously viewed"

(In reply to Matthias Versen [:Matti] from comment #4) > The back button means for me "bring me back to the URL hat I have previously > visted" but not "show me the cintent that I have previously viewed" I doubt that's true, and even if it is it's at odds with both RFC2626 (quoted in comment 0) and the intent of the HTML5 history API (which firefox supports). RFC2626 has been superseded by RFCs 7230-7237, the relevant section is now RFC 7234 section 6. The wording is a little weaker, but it still describes the purpose of the history mechanism as "to redisplay a representation retrieved earlier in a session". Rather than refer specifically to an expiration time, it refers to the apparently new "freshness model", which it says "does not necessarily apply to history mechanisms". The meaning has changed in that it now implies that a browser MAY apply the freshness model to a history mechanism, where RFC 2626 said it SHOULD NOT attempt to show the current state of the resource. https://tools.ietf.org/html/rfc7234#section-6 The HTML5 history API allows scripts to add states to the history, so that the back button can return to a previous state on the same page. This is useful on interactive pages where scripts can drastically change the page in response to user actions, possibly dynamically loading whole new interfaces. If the back button took you back to the previous URL, previous states on the same page would be inaccessible, and could only be approximated by starting again and repeating a potentially lengthy and time consuming sequence of user actions. https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history#Adding_and_modifying_history_entries Here's a page which demonstrates use of the history API: http://html5demos.com/history I don't like that this example changes the content of the location bar when it adds a history state, but if you try to load one of those URLs you get a very different response than when you manipulate the demo page. > You would get an annoying bar/dialog/whatever on manny sites with dynamic > content. Only if the notification is annoying and there are no configuration options that change that. I assume by "dynamic content" you mean pages that expire quickly, not pages which change while loaded. These pages are exactly the point - when the previous state is stored in the history, I want to see what I saw before, and automatically reloading the page means I never will. When the previous state is not stored in history, I want (to be forced to reload it myself, but since that was refused,) to be informed that I'm not seeing what I saw before. The UI I would like to have would indicate a stale page primarily by darkening the background of the location bar and brightening the reload button. I expect that would be easy for the user to distinguish without being annoying. If stale pages will never be shown, I imagine there could be a similarly unintrusive indication that an automatic reload has occurred.

(In reply to Shad Sterling from comment #5) > I assume by "dynamic content" you mean pages that expire quickly, not pages > which change while loaded. These pages are exactly the point - when the > previous state is stored in the history, I want to see what I saw before, > and automatically reloading the page means I never will. The alternative to this is that whenever I leave a page I might want to come back to later (ie almost every page), I have to remember to open the new page in a new tab, because the contents of the current page will be lost when I leave it. This should count as a data loss bug. If you want to update a page you can always refresh it, but there is no way for me to get the old contents back.