305129 - scroll position incorrect after reload

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Brian Polidoro]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050818 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050818 Firefox/1.0+

When navigating forward then back again the scroll position will be where it was
when the link was followed after reloading even if it was changed after going back.

Reproducible: Always

Steps to Reproduce:
1. Scroll down a page and follow a link.
2. Then go back to the previous page.
3. Scroll to the top of the page and then reload.

Actual Results:  
After reloading the page will be scrolled to where it was when the link was
followed.

Expected Results:  
The page should stay at the top.

This only happens with bfcache.

Comment 1

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050818
Firefox/1.0+ ID:2005081812

WFM

is there any url in particular where this happens ?

Comment 2

[Peter van der Woude [:Peter6]]

i tried it here (bugzilla) and it works.
on servers that allow caching it fails

Comment 3

[Brian Polidoro]

I see this consistantly on the tinderbox pages.
e.g.  http://tinderbox.mozilla.org/Firefox/

Because typically I'll scroll down to where I left off watching the tinderboxes
and see what checkins have been checked in since then.  Then I'll go back and
later I would scroll to the top and then reload to see if any new checkins have
come in.  And then I'll end up further down the page instead of staying at the
top.  

I had assumed that this happens anywhere.  I had tested it on a slashdot article
before as well.  

Comment 4

[Ria Klaassen (not reading all bugmail)]

Bfcache enabled shows this behaviour indeed.

Comment 5

[Mike Schroepfer]

Bryner - can you take a look?

Comment 6

[Mike Connor [:mconnor]]

WFM on WinXP 0823 and for beltzner on Mac 0823, minusing, please renominate if
you can reproduce in a current build.

Comment 7

[Peter van der Woude [:Peter6]]

(In reply to comment #6)
> WFM on WinXP 0823 and for beltzner on Mac 0823, minusing, please renominate if
> you can reproduce in a current build.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050823
Firefox/1.0+ ID:2005082311

WFM

Comment 8

[Brian Polidoro]

I still saw this in the 8-23 nightly but I see peter and I surmise Mike you too
must have been using a build a little after the 23rd nightly.  But I'm happy to
report I don't see the problem in the 8-24 nightly.

->WFM

Comment 9

[Brian Polidoro]

Ah crud.  Reopening as I didn't see it because bfcache was disabled.  I reset
viewers to 3 and I still see it.  I'll try and see if I can find what we're
doing differently that would explain the difference in what we're seeing. 

Comment 10

[Boris Zbarsky [:bzbarsky]]

Renominating per comment 9.

Brian, do you have any extensions installed?  Does this happen with a clean profile?

Comment 11

[Peter van der Woude [:Peter6]]

I have bfcache enabled and was not seeing it for the cases mentioned.

a case that does fail all the time:

1.go to http://www.tweakers.net/pricewatch
2.select something at the bottom of the page
3.press back once the new page has loaded.
result, you end up at top of http://www.tweakers.net/pricewatch

(thanks Harm)

Comment 12

[Marius Strumyla]

looks related to bug 299936

Comment 13

[Marius Strumyla]

I meant to say comment #11 is what looks like bug 299936

Comment 14

[Brian Polidoro]

I do see this in a newly created profile. 

As for bug 299936, that is similar but for me that bug happens without bfcache
so it's not the same as this bug.  And that bug does not require a reload while
this one does.  Also comment #11 seems to also be bug 299936 and not this bug.

Let me try to detail and break down the steps better:
1. scroll down a page (page A) 
2. follow a link (page B) - I let the page load fully but I don't know if it is
necessary as it happens too quick for me to go back in mid stream.
3. go back to page A - the scroll position will be where it should be which is
where it was after step 1.
4. scroll to the top of page A
5. reload page A 
6. after reloading is complete the scroll position of page A will not be at the
top of the page.  It will be where it was in step 3.

I've done this from the deer park start page at browser start as another example.

Comment 15

[Chris Beard]

resetting as a blocker, although relatively minor

Comment 16

[Brian Ryner (not reading)]

Attachment: remove LayoutHistoryState after restoring page

When a page is loaded without fastback, we restore each frame's state from the
LayoutHistoryState, and then that frame's state is removed.  Since we never
restore frame state when pulling a content viewer out of session history, this
state persists and can be incorrectly used later.  I think it makes the most
sense to just remove all of the state after restoring the page.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 193847 [details] [diff] [review]
remove LayoutHistoryState after restoring page

This looks reasonable, but we should look into not storing the state to start
with in this case (until the bfcache entry is evicted), I think...

Comment 18

[Brian Ryner (not reading)]

checked in on the trunk, leaving open for branch approval

Comment 19

[Asa Dotzler [:asa]]

can you resolve as fixed so we can get a trunk verification and evaluate for the
branch?

Comment 20

[Jay Patel [:jay]]

v.fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050829 Firefox/1.6a1.  We should get this onto the branch.

Comment 21

[Brian Ryner (not reading)]

checked in on the branch

Comment 22

[Tracy Walker [:tracy]]

verified on Firefox 1.4 -mozilla1.8 branch- Win, Lin and Mac : 2005-09-07

Comment 23

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 308910 has been marked as a duplicate of this bug. ***