currently, when the user presses the Back/Forward buttons, the page is loaded using the load flag LOAD_FROM_CACHE. this causes necko to bypass any server specified cache policy, and attempts to always take the page from the cache. the page will only be loaded from the server if the cache does not contain the page. in contrast, Netscape4x and IE will honor some of the server specified cache policies when the user presses Back/Forward. for example, a page marked with 'Cache-control: no-cache' will be reloaded from the server when the user presses Back under IE, but not under mozilla. in effect, the distinction is between session history as a list of URLs or session history as a complete historical view of what was previously viewed. we've strived to provide the latter, but unfortunately it makes us inconsistent with existing browsers and hence with content providers expectations. the problem with mozilla's behavior is that many websites (online banks, webmail apps, etc.) that enable the user to login and logout depend on the behavior of Netscape4x and IE. they expect that after the user presses logout, that the pages in session history (marked no-cache) will be fetched from the server when requested via the Back button. this allows such web apps the ability to prompt the user to login again. in mozilla, however, the web app is not contacted again, and so even after the user has supposedly logged out, they are still able to press Back to see their checking account statements again, for example. this is a really big problem, IMO. mozilla acts like IE only when the server sends 'Cache-control: no-store' because this directive tells mozilla to not put the page in the cache. this has the unforunate side effect of making view->source and file->saveAs require server hits. so, IMO encouraging web apps to send 'Cache-control: no-store' is not a good idea.

nominating for nsbranch

Comment on attachment 50981 [details] [diff] [review] v1.0 patch r=gagan

this has been a common issue and has manifested itself in several of our cache/history related bugs. This is a "good to have" for the branch.

Comment on attachment 50981 [details] [diff] [review] v1.0 patch rpotts@netscape.com

fixed-on-trunk

-> 0.9.4 branch

What's the problem that's being "corrected" here? History navigation shouldn't touch the server (unless required by a page not being in local storage at all, when the user should be warned and a fetch optionally performed). It's part of the HTTP spec. RFC2616 states: ====== 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. 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 important 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. ===== Opera have got this right I think and it (in part) adds to the speedy feel of the app by enabling you to go backwards and forwards quickly irrespective of any dubious caching directives made on the server to generate page hits.

check it in - PDT+ Darin - Let's add a list of sites to test, after this patch lands (i.e. banking sites, calendars, and toher web apps).

i talked at lenght over irc last night with paulm... hopefully, i cleared up the issues here :)

fixed-on-branch

I appreciated Darin explaining things to me in IRC. However, it still seems to me we are doing the wrong thing by moving away from what the HTTP spec suggests. As I understand from chatting this fix is supposed to fix the fact that some webapps are locking Mozilla out because of it's current behavior, not liking that people can go back to pages they have seen after logging out for example. I'd suggest that an appropriate fix to this would be evang, getting such apps to use no-store rather than no-cache as that is what they should be using. The use of no-store may cause problems with view-source/printing but that is a seperate Mozilla bug (the _current_ page should be available in memory for such procedures regardless). OTOH I understand that this may be an appropriate quick fix for immediate problems that would require a lot of work (evang and upgrading the cache/history/view-source/printing subsystems) that may not be solvable in a reasonable time. If so I think a bug should be filed on undoing this change, dependant on other bugs involving those subsystems. Does that sound like a reasonable deal?

I am a mozilla user who is very unhappy to see this change in 0.9.5. I wrote a post to that effect at http://www.mozillazine.org/talkback.html?article=2054&message=75#75, which I will not repeat here. I also point out the comments in bug 33269, which support the position that users want back/forward to be fast. I think the excerpt from the HTTP spec captures the desired behavior precisely, and am surprised to see it (apparently) casually ignored. Note it is clear from the spec that back should not reload regardless of cache-control attributes (even no-store): "History mechanisms and caches are different.". I am especially surprised to see this change made for the sake of web authors who want to subvert traditional browser functionality. The explanation in the original report ("this allows such web apps the ability to prompt the user to login again") makes little sense, because the app can still prompt the user to login again the next time he clicks. There is a security concern (users leaving sensitive information in their history), but breaking the browser is a poor way to handle it. Remember: you can't change history. ;-)

actually, this change makes us more like existing browsers... and that is exactly the reason why it was done. the HTTP/1.1 spec makes a suggestion about what would be nice to have.... however, it does not require this. so, we started out trying to do what the spec suggests, and found that we were deviating from the normal browser behavior w.r.t. back/forward. compare mozilla today to Netscape4.x or IE, and you will see that we behave similarly w.r.t. to back/forward behavior.

Darin, I understand your position. But you are holding up consistency with other browsers and the interests of some web developers (whose argument I, a web developer, find dubious), against the standard (granted, only a SHOULD), the interests of users, and traditional functionality. It just seems poorly considered. I say the interests of users, because 1) I am convinced that users want a fast back (as cited previously), 2) reloading eliminates the ability to see an old page unchanged, even for a sophisticated user who knows that's what he wants, and 3) the principle of least surprise: "history" implies static, "back" implies what I was previously seeing. I say traditional functionality, despite the fact that some browsers behave differently, because the motivation for the change seems to be to allow not only refreshing an old page, but also showing something entirely different (eg, a login screen). This is just not what back was meant to do. FWIW, here's a practical example of lossage. I'm reading a discussion on slashdot, and follow a link. When I go back, mozilla attempts to put me in the same place as before. But because the page was reloaded, the scores have changed and the posts are in a different order, so where I end up is basically random. Further, some posts I haven't read might have moved up, so I have to read the whole page again to avoid missing anything.

i think you are assuming that this change effects the back behavior in all cases, which is not true. we will only validate cached content on back when the server sent the response using a restrictive cache control HTTP header (such as 'Cache-control: no-cache'). if you notice, this does not apply to many dynamically generated websites, such as slashdot.

Only dynamic sites are likely to be using no-cache. (It makes no sense for static ones to do so). And as for Slashdot not using it, I guess you weren't logged in: ==== HTTP/1.0 200 OK Date: Wed, 17 Oct 2001 01:16:49 GMT Server: Apache/1.3.20 (Unix) mod_perl/1.25 X-Powered-By: Slash 2.001000 X-Fry: Leela, there's nothing wrong with anything. Cache-Control: no-cache Pragma: no-cache Content-Type: text/html X-Cache: MISS from cache.syd.integrity.net.au X-Cache-Lookup: MISS from cache.syd.integrity.net.au:3128 Connection: close ====== Many other 'dynamic' sites use no-cache simply so more adverts are served. I frankly don't give a crap what NS4 or IE do. Maintaining the status quo is a ridiculous argument. You don't compete with IE by trying to clone it, you compete with IE by being better than it. Ignoring cache-control directives on history navigation as the http spec suggests makes for a vastly improved user experience, it's that simple. Opera have it right and it's one of the factors that make it my primary browser when in Windows.

unfortunately, because of online banks which expect and require this behavior of browsers, we have no choice but to either accept this reality or expect to be blocked from many online banks, and all such banks have very little problem blocking mozilla/netscape users on account of this issue. so, the "best" option in my mind would be something like the addition of a pref that allows back/forward to always pull from cache. it is unlikely that this pref would ever be enabled by default until mozilla truly has a "kiosk mode."

A pref on this would certainly be a significant improvement. A possible tweak to this would be to differentiate between http and https connections and have a pref for each. Let the banks have their way with the default setting for https and the user have their way for http. It's a tad crufty but I think it'd mean everyone would be happy. The user would have a snappier browser for 99% of their browsing and the banks would have something that fits in with their current (misguided) ideas. Ultimately I'd prefer such problems with banks to be solved with evang (banks should be using no-store if they aren't already and their app should be handling what happens with outdated pages, you can't trust a client anyway) but I can see that some pragmatism is needed.

>unfortunately, because of online banks which expect and require this behavior of >browsers This new change may create a false sense of security. Are we no longer cacheing "no-cache" pages or just disabling the UI for retrieving them? If it is the latter then I hope my bank uses "no-store" because there are numerous mechanisms for retrieving this information from the cache outside of Mozilla. Once upon a time I had to close my browser window to ensure removing sensitive information from session history. My bank even closed the window for me when I clicked "logout". I think that is the correct behavior according to the RFC and is what most users would prefer. Site providers should let users know what to expect and instruct them to end the session for security reasons. In the interim lets give it a pref so people can choose.

we should carry this discussion forward on a new bug.

verified on branch: WinNT 2001-10-22-18-0.9.4 Linux rh6 2001-10-22-17-0.9.4 Mac osX 2001-10-22-18-0.9.4

"Fixing" this bug caused bug 105395, "Moving back in history doesn't remember scroll position sometimes".

The behavour caused by this patch (which was rushed through in 90 minutes) is broken by design. See bug 112564 for backing this out.

(In reply to comment 24) > (which was rushed through in 90 minutes) Rushed through in 90 minutes, and surviving almost ten years of complaints and criticism. Congratulations, Mr Fisher!