101832 - back/forward buttons should use LOAD_NORMAL + VALIDATE_NEVER

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[Darin Fisher]

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.

Comment 1

[Darin Fisher]

nominating for nsbranch

Comment 2

[Darin Fisher]

Attachment: v1.0 patch

Comment 3

[Gagan]

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

r=gagan

Comment 4

[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 5

[rpotts (gone)]

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

[e-mail]

Comment 6

[Darin Fisher]

fixed-on-trunk

Comment 7

[Darin Fisher]

-> 0.9.4 branch

Comment 8

[Paul McGarry]

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.

Comment 9

[Jaime Rodriguez, Jr.]

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

Comment 10

[Darin Fisher]

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

Comment 11

[Darin Fisher]

fixed-on-branch

Comment 12

[Paul McGarry]

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?

Comment 13

[Andrew Pimlott]

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

Comment 14

[Darin Fisher]

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.

Comment 15

[Andrew Pimlott]

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.

Comment 16

[Darin Fisher]

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.

Comment 17

[Paul McGarry]

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.

Comment 18

[Darin Fisher]

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

Comment 19

[Paul McGarry]

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.

Comment 20

[Kevin Wade]

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

Comment 21

[Darin Fisher]

we should carry this discussion forward on a new bug.

Comment 22

[Tom Everingham]

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

Comment 23

[Jesse Ruderman]

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

Comment 24

[Bradley Baetz (:bbaetz)]

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

Comment 25

[Alain Knaff]

(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!