443477 - "back" button re-fetches data instead of re-loading cache

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Sam Steingold]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080417 Remi/2.0.0.14-1.fc6.remi Firefox/2.0.0.14 pango-text
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080417 Remi/2.0.0.14-1.fc6.remi Firefox/2.0.0.14 pango-text

when I hit the "back" button, I _never_ want FF to go fetch the page anew.
I always want it to redisplay what it already has in the cache.
instead, I not only get to wait for the page to download,
I also get the message "the page requested resulted from a POST request, reloading it will re-POST the data".

Reproducible: Always

Steps to Reproduce:
1.load any page
2.click any link
3.click back button
4.watch the "contacting ..." message in the status line in the bottom
Actual Results:  
the site is contacted to re-fetch the page I just left

Expected Results:  
the page is re-rendered from cache.


if I want reload, I would hit the reload button.
back is NOT reload.

Comment 1

[Sam Steingold]

the same applies to the forward button, of course.

Comment 2

[Joey Twiddle]

Summary: Users want the cache to be used when nagivating Back/Forwards or using History (possibly even Bookmarks).  The only time the user really wants the cache to be checked/updated is when navigating forwards (by cliking links, buttons etc.) or when hitting Refresh.

Absolutely agree with the original request.  This could be a new policy for browser.cache.check_doc_frequency.

The current default policy is: "Check for a new version when the page is out of date."

I think many users would appreciate a faster policy: "Check for a new version when the page is out of date, and the user has not just returned here by the Back button"

Getting the right policy for what users really want is important...

We could supplant "history navigation" for "the Back button", which would mean using the cache when returning to a page already viewed (this session?), e.g. via Back, Forward, History menu or Undo Close Tab.

I suggest that clicking a link should not qualify.  Navigating forwards to a page in the manner intended by the website should be handled as normal by the website, not forced from the cache!

The reasons we need this:

* When a user uses the Forward or Back button he expects the page to appear exactly the same as it was when he was last there.  Also he wants it to be fast.  Most users do not usually want the page to be checked/reloaded.

* Many websites are now replying in their headers that the page is different every time we load it, and that it should expire from the cache in the next few seconds.  (This might be so that the site can serve a new set of adverts, or just keep better track of the navigation of their users.)  This is breaking the user experience.  Often the user would prefer the cached copy but they do not get it.

This might require some changes to internal caching policy.  E.g. we may need to keep some files which previously the cache would have discarded due to their expiry header, in case we need them again when the user goes Back.

I was enjoying the policy #2 "Never check for a new version - always load the page from cache." for a while, but finally met the problems when navigating forwards.  The lack of checking when navigating forwards meant that when I made a Wiki edit and POSTed it, the "new" wiki page did not display the changes since I last viewed it, and when I navigated onward again to the Edit page, I got the cached version also without the changes!  I think a more useful policy than this would be "Only check for a new version when navigating forwards".  I'm not sure how different that is from the suggested policy above.

Comment 3

[Sam Steingold]

Thanks for your support.
As for "forward", I see your point.
However, cache still could sometimes be reused.
If the site thinks that cache is obsolete and should be discarded, 
you can make the "refresh" button blink, but still show the cache.
this might not necessarily be the default behavior though, 
but controlled with a user setting "rely on cache more".

Comment 4

[Joey Twiddle]

My apologies.  It seems by default Firefox does not contact the webserver when going Back.  (Maybe it does if there is certain Javascript or AJAX on the page.)

It still seems to me that going Back is slow.  I think the problem is that Firefox re-builds the DOM from all the files on the page, which can take some time for large pages.

It might be nice if Firefox kept the final DOM of the previous page in memory, so that going back could be fast, at least once.

Comment 5

[Sam Steingold]

maybe the DOM could be kept on disk together with the cache?
the bottom line is that "back"/"forward" should be blindingly fast,
as in "no processing is performed", so whatever processing has to be done,
should be cached to disk.

Comment 6

[Joey Twiddle]

The BetterCache addon helps address some of my problems:

https://addons.mozilla.org/en-US/firefox/addon/6371

Apart from acquiring the files, the other thing that takes time is building up the DOM again.

On a slow PC with enough memoty, I would welcome a cache of the DOM of the previous page.  Maybe it could cleanup after a few minutes if the user is now focused on other tabs.

Comment 7

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.12 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles
Also, please consider using the most recent Firefox 4 beta build, your bug may be resolved there.

Comment 8

[Sam Steingold]

Mozilla Firefox 3.6.12, Copyright (c) 1998 - 2010 mozilla.org
still the same behavior in safe mode.
e.g., visit slashdot.org, click on any link, then on "back" button.
observe ff contacting zillion of sites.

Comment 9

[Joey Twiddle]

Firefox 4 is preserving the DOM of back-pages now.  Nice :)

Comment 10

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.