User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+ The back/forward cache becomes confused as to what page to load from the cache when dealing with bug lists. The bug list will be loaded from the cache when you go back or forward to it, but the page you go back or forward to from the buglist will not be loaded from the fast cache. Reproducible: Always Steps to Reproduce: 1. Go to a large, slow to load page (one that will be stored in the back/forward cache). An LXR page will do. 2. Go to a bug list (one that is bookmarked, for example). 3. Go back to the large, slow to load page. The page will not be fetched from the fast cache and will be instead loaded slowly. Actual Results: Page is loaded slowly, from the memory cache. Expected Results: Page should be loaded quickly, from the back/forward cache. This occurs on all platforms. The flaw is apparent on GNOME bug lists, Mozilla bug lists, and other Bugzilla installations.

I am seeing the same thing with the new error pages that were recently enabled. Try this: 1) Load a big page that takes a while to finish. 2) Go to a non-existant address, http://www.stsoeiprfsdifjsldfjlsdfjsdfljsdf.com/ 3) Go back. Page is not loaded from the fast cache. I think this bug has something to do with the redirect that occurs when going to a bug list, or a non-existant site.

I do not believe that the bug lists have any redirects. The unique thing about the bug list page is the use of "Content-type:multipart/x-mixed-replace" It appears other multipart types also break : http://maxradi.us/post/bugzilla/mixedreplace/mixedreplace.cgi http://maxradi.us/post/bugzilla/mixedreplace/mixed.cgi Here's the CGI script: #!/bin/sh echo "Content-type: multipart/x-mixed-replace;boundary=BOUNDARY" echo echo --BOUNDARY echo "Content-type: text/plain" echo echo This is the test page echo echo --BOUNDARY-- This may or may not be related to the same problem with the error pages. Since this only invalidates the cache, I renamed it to avoid confusion with the case that the cache becomes corrupted or does the wrong thing.

If the problem isn't any more severe than failing to cache the page, I think we can afford to ship with this.

(comment 1 was fixed by bug 299547)

Reassigning my bugs, since I'm not actually working on them.

Sam, do you still see this problem? (not sure Sam is still around)

I cannot reproduce the problem. The bfcache seems to work correctly on bugzilla now. Whether that is because bugzilla was updated or Gecko, I don't know. I will mark it worksforme.

Sam, is your comment 7 based on using FF 2 or trunk? Henrik, is your verify based on FF 2 or trunk?

It was based on comment 7. But running a test with Minefield shows that it's working fine.