Back/forward cache is invalidated on bug lists

VERIFIED WORKSFORME

Status

()

Core
Document Navigation
VERIFIED WORKSFORME
13 years ago
9 years ago

People

(Reporter: Sam Allen, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: CLOSEME 2008-05-22, URL)

(Reporter)

Description

13 years ago
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.
(Reporter)

Updated

13 years ago
Blocks: 274784
(Reporter)

Comment 1

13 years ago
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.

Comment 2

12 years ago
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.
Assignee: nobody → bryner
Summary: Back/forward cache becomes confused on bug lists → Back/forward cache is invalidated on bug lists
If the problem isn't any more severe than failing to cache the page, I think we
can afford to ship with this.
Target Milestone: --- → mozilla1.9alpha
(comment 1 was fixed by bug 299547)
Reassigning my bugs, since I'm not actually working on them.
Assignee: bryner → nobody

Comment 6

10 years ago
Sam, do you still see this problem?   (not sure Sam is still around)
Whiteboard: CLOSEME 2008-05-22
(Reporter)

Comment 7

10 years ago
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. 
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
OS: Windows XP → All
Hardware: PC → All
Target Milestone: mozilla1.9alpha1 → ---

Comment 8

10 years ago
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.

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
You need to log in before you can comment on or make changes to this bug.