Moving back in history doesn't remember scroll position sometimes




17 years ago
10 years ago


(Reporter: db, Assigned: radha)




Firefox Tracking Flags

(Not tracked)





17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.5+) Gecko/20011016
BuildID:    2001-10-16-06

Sometimes, when moving back in history, I am taken to the top of the page
instead of the previous scroll position of this page. This does not only happen
with named anchors (as described in bug #59774), but also on every Slashdot
page, which contain no named anchors... :(

Reproducible: Always
Steps to Reproduce:
1. Browse to, wait until Mozilla has loaded the page.
2a. Scroll down to the bottom of the page and select "Read More..." on any
story. Wait until the page loaded.
2b. Scroll down a bit and select a header of a Slashbox (one of the right-side
boxes) that does _not_ contain any script or so (e.g. the "MozillaZine" box in
my configuration: Wait until the page loaded.
3. Press the back button.

Actual Results:  Mozilla takes me to the top of the page.

Expected Results:  Mozilla should have taken me to my previous scroll position
of the page.

This bug is quite new. I think have used a 2001-09-25 build before updating to a
2001-10-08 nightly. The 2001-09-xx builds I have used didn't have this bug, only
the newer ones... :(

Comment 1

17 years ago

*** This bug has been marked as a duplicate of 58785 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 2

17 years ago
I'm going to un-dup this bug.  Bug 58785 is a longstanding, intermittent bug,
marked Future.  This one is a new regression which happened in the past few
weeks; scrollbar memory was working fine, and now it's not working at all, and
we need a bug to track this new regression.  Several of us are seeing this on
Linux as well.
Severity: normal → major
Keywords: regression
OS: Windows NT → All
Hardware: PC → All
Resolution: DUPLICATE → ---


17 years ago
Ever confirmed: true
I couldn't follow the step 2b described above. However I spent some time on the
site using a latest build reading thro' several articles on and I
couldn't reproduce it. I fixed a bug  week related to scrollbar position
restoration when history.back()/forward()/go() is used. Could this be fixed by
that fix? That bug was 101682.

Comment 4

17 years ago
I couldn't follow 2b either (there are no boxes on the right hand side of the
page after I've scrolled down past the initial headers; all I see are comments
from people, no boxes).

However, if I change 2b to be: click on any link to another response, then click
back twice (not just once -- the first back is correctly scrolled, or at least
close), I go back to the main slashdot page and it's scrolled up at the top
again, not the bottom as it was when I left it.

This is with a commercial 2001102208 build (i.e. yesterday), and I was seeing it
a lot yesterday in random browsing with this build.


17 years ago
Target Milestone: --- → mozilla0.9.6

Comment 5

17 years ago
*** Bug 106472 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
Hello Guys,

I just wanted to tell you that I am still seeing this problem with a quite
recent build (having just updated to 2001103003). :(

After Radha and Akkana "complained" about my 2b step, I couldn't reproduce it
either. However, I have just tested it and I can reproduce 2b now again.

I also noted some other strange behaviour which might be linked to bug #105097:
last week I quit and re-started Mozilla and suddenly my visited links started to
change color again (that's what bug #105097 is about), and at the same time I
had no problem at all w/ the history! I then thought that it had something to do
with re-starting Mozilla but I could not reproduce this behaviour at all: no
visited links changed color anymore and history problems persisted, no matter
how often I re-started Mozilla... :((

So it seems to be a strange problem, at least for me, w/o having insight in the

bye, daniel :(
Daniel: Have you tried a fresh profile? You can manage/create profiles with
"mozilla.exe -profilemanager".

Comment 8

17 years ago
The occurring of this bug seems to depend on whether the page is dynamically
generated or not. Also, on Slashdot frontpage this occurs only when I'm logged
on to my /. account. 

The bug is reproducible every time on pages like this:
(Go to that page, scroll down and follow some link, then click "back".)

On pages like this (not generated dynamically?) it does not occur:

Hope this helps...
On a build from 10/30, I see the problem as Joni K has described above. I also
see it in's main page. shall try to see what's going on.

Comment 10

17 years ago
Hello Alex,

I have now tried a fresh profile and the bug is still there (having changed not
a single setting in the new profile).

However, it seems as if John has been right. At least for /., static pages seem
to keep their scroll position, dynamic pages not.

Comment 11

17 years ago
Another case in which I'm seeing this:

1.) Go to
2.) Scroll and click on a link on that page
3.) Hit the back button and, most likely, it'll go back to the top of the page.

There is some sort of redirection(I don't believe it is a 302) in While accessing the page thro' history, the page comes for
rendering twice. THe scrollbar position is restored when the page is rendered
for the first time. But a consecutive capture (when it is loaded for the second
time) eventually erases the previous restoration. Therefore the scrollbar is
eventually drawn in default position. 

Comment 13

17 years ago
I am also seeing the bug on The bug is not
triggered, when this page is loaded locally (which I tried in order to locate
the problem...). You can see that by saving the page to disk and then load it
from there. But beware: most links on this page refer to relative stored pages. :)

I don't know if that helps...?

Comment 14

17 years ago
When I first notice the bug on, I checked to see if it was caused by
relative vs. absolute links and that doesn't appears to be the case.

Comment 15

17 years ago
*sigh* That does _not_ appear to be the case.
Sorry about the spam.
Depends on: 108267
I think this is a symptom of bug 108267.
108267 got fixed today and it has fixed this bug on  At, I could not reproduce the bug in windows. But it did
show up in linux.  

Comment 18

17 years ago
Shall I file a new bug for or change the URL on this one?

I haven't tested on the latest nightlies due to all the blockers currently in
the tree.
Let me try this out tomorrow in the official builds and then we'll see.

Comment 20

17 years ago still doesn't restore scroll position correctly for me.  I'm
running build 2001110703 on Win98.
I can't reproduce this problem in linux as well as in windows in today's builds. and seem to work just fine. 
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 22

17 years ago
With builds 2001-11-07-21 and 2001-11-08-21 on Linux this bug is still present.
I don't see it on, but on it's there just like before
(see comment #8).

Comment 23

17 years ago
Please reopen this bug.  I see it on build 2001111303 on Win98.

Steps to repro:
1) login to
2) go to the homepage
3) scroll down and then click on Read More of a story
4) wait until the story page is done loading (so you don't run into bug 92820)
5) click the back button

The homepage should restore its scroll position; it does not.

Comment 24

17 years ago
I don't see the bug anymore on 2001110908/Linux but I am seeing the
slashdot bug as described above... it also happens if you click on a link on the
comments page and then click back.
I'm reopening (I know the build is a few days old, but there haven't really been
any linux builds except for the gcc 3.0 ones and I don't have the right libs to
run those).
Resolution: FIXED → ---
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 25

17 years ago
Curiously, I don't see the problem.  Today's build is scrolling nicely for me on
slashdot so far.  I've been careful about waiting for each page to finish
loading ... could that be the difference?

Comment 26

17 years ago
I've waited for pages to finish loading as well, and I do see the problem.
But on slashdot frontpage it only occurs when you're logged on, did you note that? 

Comment 27

17 years ago
I'm seeing it on a cvs build from last night... and, yes, I believe someone
mentioned that you had to be loggen in (i.e. page with dynamic content).

Comment 28

17 years ago
I don't log on to slashdot, so that would explain the disparity.

Comment 29

17 years ago
Akkana: even if you don't log on, you can still reproduce this bug; see 
comment #8 

Comment 30

17 years ago
reproduces nicely with the link from comment #8 (added to url field)

Comment 31

17 years ago
bug 111793 has an url where it's 100% reproducable. META refresh involved?

Comment 32

17 years ago
*** Bug 111680 has been marked as a duplicate of this bug. ***
The url provided above from comment #8, has cache-control directive 'no-cache'.
This prevents the page from being saved in the cache for future loads. On such
pages, session history does not save form element values and scrollbar
positions, since the page will be fetched fresh from the server for *all*
subsequent loads including through history.  
Marking this won't fix, as we don't intend to duplicate this behavior on pages
that request 'no-cache'. 
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 35

17 years ago
Well, that's a shame. As it is, Mozilla is pretty much unusable for reading long
discussions on slashdot. (I guess I'll just have to use Konqueror for that...)

Should there be an evangelism bug for slashdot & no-cache directive, or something?

Comment 36

17 years ago
sorry for spam, but you could use another feature for such discussions on
slashdot. Just open a new tab, for the links instead of just clicking on them.
If you're used to this you don't have problems with scrolling positions and have
some other advantages. And tabs don't need much time to open :)

But still it's a shame that this bug is wontfix :(

Comment 37

17 years ago
A wontfix is wrong for this bug. Pages should be cached for the back/forward
session history regardless of the "no-cache" header. When you click back you
want to go back to what you've just been reading (if you don't then you click
back then reload). As well as breaking remembering the scroll position it also
makes session history slower. In Opera the back/forward performance is amazing.

Reopening this bug because it is a bug and makes us look bad compared to our
competitors (not just Opera and IE but previous versions of Netscape 6.x), does
Netscape really want to ship MachV with what will appear to users as a regression?
Resolution: WONTFIX → ---
> Pages should be cached for the back/forward
> session history regardless of the "no-cache" header.

See bug 112564 and bug 101832 for that discussion.  Please note the request to
not spam bug 101832 with further comments; bug 112564 would seem to be a more
appropriate forum.

The problem has nothing to do with session history but rather with caching
behavior, so this bug is really not the right place for it.  re-resolving;
please take this up in the relevant cache bugs.
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX


17 years ago
Blocks: 33269

Comment 39

17 years ago
This was fixed in bug 112564.


16 years ago
No longer blocks: 33269


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