41228 - back arrow loads very old page from cache (build 2000060102)

Status: VERIFIED DUPLICATE of bug 44226

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

Description

[lutetium]

I've noticed sometimes when I click the back arrow the page appearing on my 
screen is an old page from my cache instead of the page I most recently viewed.

For instance, I can read an article on Slashdot and after clicking the back 
arrow I might see a list of articles from yesterday or last week instead of the 
list I looked at two minutes ago.

Comment 1

[Radha on family leave (not reading bugmail)]

I'm guessing this is related to frameset pages. SH in frameset pages don't work 
right yet. For lack of specific info, marking dupe of 41019

*** This bug has been marked as a duplicate of 41019 ***

Comment 2

[Claudius Gayle]

marking VERIFIED Dupe

Comment 3

[lutetium]

Are you sure this is a duplicate bug?  It's not going back to the page before
last, it's using the same URL as the last page.  However, rather than reloading
the page or showing the page as it was a few minutes before, it's simply reading
files that were cached several days ago.  And My cache is set to stroe for 0 days...

Comment 4

[lutetium]

I'm really not sure what extra info you need.  It's a rather intermittent bug,
but here's essentially what happened:
I went to http://slashdot.org and saw today's headlines.
I clicked the READ MORE link to read an article.
I clicked the back arrow.
I was returned to http://slashdot.org, only instead of today's headlines, I saw
yesterday's headlines (Actually the previous week's headlines the first time
this happened)

Had this been a dupe of 41019, I should have bee taken to an entirely different
URL, correct?

Comment 5

[Claudius Gayle]

No that doesn't seem correct by my reading. upon further inspection - this sounds pretty much the same to me. bug 41019 is 
pretty much a dupe itself anyway. there is still a lot of work to be done(which is going on right now) with SH and framesets, so it's 
probably best to wait and see for a few days(IMO)

Comment 6

[lutetium]

I just had the same problem again in build 2000071008.
Looking at bug #41019 and the bug it is a verified dupe of, these are clearly
different.

41019 causes the back arrow to take you to  a url before a frameset, whether
that was the previous page or not.

This takes you back to the correct URL, but rather than showing the page as it
was when viewed minutes ago, the page is seen as it was a few days ago. So we're
not going back to before a frameset, we're going back to yesterday's cache.

I don't know how you can claim this is frameset related when the pages in
question didn't even use frames.

It looks to me like mozilla loads the page when I type the URL or click a link,
but fails to update the cache if the page has already been visited.  Thus when I
click the back arrow and load the page from cache, I see yesterday's headlines
instead of headlines from five minutes ago.

Comment 7

[lutetium]

Steps to replicate:
 1	Install build 2000071008.
 2	type http://slashdot.org in URL bar.
 3	Let browser load page.
 4	close browser.
 5	Wait 24 hours.
 6	repeat steps 2&3
 7	click Read more or any other link on page
 9	click back arrow
You should now see the page you viewed in step 3, rather than the page from step 6.

Comment 8

[Radha on family leave (not reading bugmail)]

accepting. session hitory does not work well with cache yet. It is the next on 
my plate once I clear the nsbeta2+ bugs

Comment 9

[Blake Ross]

hmm..I know we have bugs on the cache problem.  This sounds very much like bug 
44226 to me (compare kin's original reproduction steps to the slashdot example 
in this bug)

*** This bug has been marked as a duplicate of 44226 ***

Comment 10

[Blake Ross]

ah, there it is.  This is actually bug 40449, but I'm not going to redup 
because it would cause a lot of unnecessary spam from the dependency bug.  In 
any case, I think bug 44226 (to which this has been duped) is just another dup 
of 40449 anyways...

Comment 11

[Scott Brodmerkle]

The bug this is duped against has been duped against (40449) has been FIXED, and
I'm not seeing this behavior anymore. Verified dupe.