Closed Bug 105395 Opened 23 years ago Closed 23 years ago

Moving back in history doesn't remember scroll position sometimes

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla0.9.7

People

(Reporter: db, Assigned: radha)

References

(
URL
)

Details

(Keywords: regression) 

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 http://www.slashdot.org, 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: http://www.mozillazine.org). 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... :(


*** This bug has been marked as a duplicate of 58785 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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
Status: RESOLVED → UNCONFIRMED
Keywords: regression
OS: Windows NT → All
Hardware: PC → All
Resolution: DUPLICATE → ---
Status: UNCONFIRMED → NEW
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 slashdot.org 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.
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.
Target Milestone: --- → mozilla0.9.6
*** Bug 106472 has been marked as a duplicate of this bug. ***
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
code...

bye, daniel :(
Daniel: Have you tried a fresh profile? You can manage/create profiles with
"mozilla.exe -profilemanager".
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:
http://slashdot.org/article.pl?sid=01/10/24/067209
(Go to that page, scroll down and follow some link, then click "back".)

On pages like this (not generated dynamically?) it does not occur: 
http://slashdot.org/articles/01/11/01/0111243.shtml

Hope this helps...

On a build from 10/30, I see the problem as Joni K has described above. I also
see it in slashdot.org's main page. shall try to see what's going on.
Status: NEW → ASSIGNED
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.
Another case in which I'm seeing this:

1.) Go to http://www.debian.org/MailingLists
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
www.slashdot.org. 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. 
I am also seeing the bug on http://www.debian.org/MailingLists. 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...?
When I first notice the bug on debian.org, I checked to see if it was caused by
relative vs. absolute links and that doesn't appears to be the case.
*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 slashdot.org.  At
debian.org/MailingLists, I could not reproduce the bug in windows. But it did
show up in linux.  
Shall I file a new bug for debian.org 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.
slashdot.org 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.
slashdot.org and debian.org seem to work just fine.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
With builds 2001-11-07-21 and 2001-11-08-21 on Linux this bug is still present.
I don't see it on debian.org, but on slashdot.org it's there just like before
(see comment #8).

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

Steps to repro:
1) login to slashdot.org
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.
I don't see the debian.org 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).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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?
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? 
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).
I don't log on to slashdot, so that would explain the disparity.
Akkana: even if you don't log on, you can still reproduce this bug; see 
comment #8 

reproduces nicely with the link from comment #8 (added to url field)
URL: http://www.slashdot.org → http://slashdot.org/article.pl?sid=01...
bug 111793 has an url where it's 100% reproducable. META refresh involved?
*** 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'.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
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?
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 :(
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?
Status: RESOLVED → REOPENED
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Blocks: 33269
This was fixed in bug 112564.
No longer blocks: 33269
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.