Closed Bug 58785 Opened 24 years ago Closed 22 years ago

Moving back/forward through a website can lose your scroll position on the previous page

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: marlon.bishop, Assigned: eric)

References

(
URL
)

Details

As an example of this please find a website with large amount of varied content
(text and images both) and scroll somewhere towards the middle, but where a link
would also be. (To reproduce this, use example url provided and scroll down to
the "Gran Turismo 2" section and click the link titled, "Texture smoothing on".
Now return by hitting the back button)

When you selected the link and then return BACK to your previous page, the
browser redraws the entire page and the content you last viewed is no longer in
view.  It's now scrolled somewhere else, and you loose your place.

What happens is very annoying, because you cannot page back and forth very
easily, every time you do, you have to scan and remember the last position of
the page. If you had several links you wanted to check and were in a long
document, it would be really frustrating to relocate yourself every time.

This is also troublesome for people who are on slow connections, as you begin
reading some content, the rest of the page loading, the tables and images expand
the layout, and you loose your place.
what builds are you you using? trunk or netscape branch?
Summary: paging back and forth through a website can loose your position on the previous page → paging back and forth through a website can loose your position on the previous page
Sorry, Netscape 6 branch build 20001101. Notice same behavior on win 
looks like we start to do the right hting here but the reflows change our
position. bug 46877 (fixed) and bug 47350 (the bugzilla exception to 56877) seem
to miss the position totally.  This may be something that belongs to Layout but
over to History first.
Assignee: asa → radha
Component: Browser-General → History
QA Contact: doronr → claudius
I think pollmann should check this out.
Assignee: radha → pollmann
I noticed that this page has a rather large and complex table layout - perhaps
tables changing the width of the document late in the layout process is causing
this?

I am pretty sure Session History is doing the right thing - moving to layout.
Giving this to Eric as he is the one most familiar with what we do with the
scroll position now.

Changing platform to All - I see this on Linux too.  Doesn't look like a
showstopper for RTM because the position is restored correctly for most basic
pages still.
Assignee: pollmann → evaughan
Component: History → Layout
OS: Mac System 8.5 → All
targeting
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 88498 has been marked as a duplicate of this bug. ***
*** Bug 91764 has been marked as a duplicate of this bug. ***
This only seems to happen mostly (maybe only) when the page you are viewing when
BACK is pressed is still loading.
*** Bug 93713 has been marked as a duplicate of this bug. ***
*** Bug 93855 has been marked as a duplicate of this bug. ***
*** Bug 95036 has been marked as a duplicate of this bug. ***
Clarifying summary for easier querying.
Summary: paging back and forth through a website can loose your position on the previous page → Moving back/forward through a website can lose your scroll position on the previous page
Confirming that this bug still exists on Linux 2001081514. It is correct on html
pages that if you let the following page load completely the scroll position
will store fine but if you switch back before that point you're always back at
the top of the page even if there are no complicated tables involved.

ADDITIONAL NOTE! Browsing any FTP site, the scroll position is lost even if the
next page loaded. This is evident on mozilla's ftp site. It's difficult to click
through the nightly build directories.
*** Bug 96230 has been marked as a duplicate of this bug. ***
*** Bug 98937 has been marked as a duplicate of this bug. ***
As Jason pointed out, it seems to happen when the link you click on is being loaded.

For example: http://www2.mrbrklyn.com/wtc/
This is a directory listing produced by apache. 
No tables. 

Click one one of the pictures, and while it's still loading click back. Your
position on the page is lost. If you press back when the page is done loaded,
your position on the page will be lost.
The last sentence should have said "If you press back when the page is done
loading, your position on the page will be misplaced."
*** Bug 105395 has been marked as a duplicate of this bug. ***
I object to calling #105395 a duplicate of this bug. Until some weeks ago I had
no problem w/ the history. It is only since this month that there is a problem
on Slashdot. Most other sites work OK for me.

The difference is that I am always taken to the top of the page. Please have a
look at my more detailed description in #105395.

However, since I don't know anything about the internals or may have missed
something in the descriptions of this bug, it may be that I am completely wrong
here...

bye, daniel :)
One more comment:

I tried the original description and found out that I am also being taken to the
top of the page. So it looks like bug #105395 is a duplicate of this bug. The
only thing bugging me is that I didn't have this problem until a few weeks ago
and this bug is quite old, so I thought that this bug doesn't cover my case. But
as I said before I may be wrong...
I agree with Daniel -- we need a bug to track the new recent regression, which
several of us are seeing, and this Futured bug clearly isn't it.  So I've
un-duped bug 105395.
As Asa mentioned in comment 3, the bugzilla problem is bug 47350.
*** Bug 105806 has been marked as a duplicate of this bug. ***
I haven't noticed this problem for a while now (barring bug 47350).  Close this
bug?  The given URL testcase works just fine for me now with w98 build 2002011710.
I agree. I'm no longer seeing this.
*** Bug 113094 has been marked as a duplicate of this bug. ***
Oops! 2002011716
I'm still seeing this in connection with anchor tags.

- Go to http://www.mozilla.org/editor/editor-embedding.html
- Scroll down to "Steps to embedding" and click on the first link, "editing
session multiple-editor support" (goes to #Fixing_editor_rooting in the same doc)
- Click back (goes to top of doc, not where you were scrolled).

I hit this fairly often.
Akkana: You see bug 59774 "scroll position not remembered if URL contains named
anchor"

mrmazda: The problem on Mozilla buglists is bug 47350 "Current scroll position
not retained, reloading multipart/x-mixed-replace"
FYI: I see this CONSTANTLY while reading slashdot (http://www.slashdot.org)
comments. If you are reading through a long (more than a screen) pageful of
comments to an article, and follow a link within one of them, no matter what,
when you press [BACK] you end up at the top of the article. 

It doesn't matter whether the target page page has fully loaded yet or not when
you press back.

This may have something to do with no-cache tags being sent, but IE handles this
correctly. I've become accustomed to opening links in a new tab now to get
around this.
OOps, sorry...

Additional info for above:

Mozilla 0.9.7 -- Gecko/20011221

Perhaps there are fixes in recent builds, I will try those ;-)
Mark: You didn't specify your OS, but you can get more recent builds here:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/

For win32: you want mozilla-win32-talkback.zip
For x86 Linux: mozilla-i686-pc-linux-gnu-installer.tar.gz

Or, if not one of those two, just dive into the ftp directory :). As always, be
sure to delete your old Mozilla directory before installing the new one.

PS It doens't do much good to post in a bug if you're not going to be around to
hear the response -- adding you to the CC list ;). 
Agree, slashdot issue from Comment #33 is fixed using 2002020108 ;-) 
...anxiously awaiting the 0.9.8 release. =)
So nobody is seeing this problem anymore then?
I haven't seen it for ages.

Long time since I noticed it. Slashdot works OK.
I see this when surfing Javadocs. 
to repro:
go to http://java.sun.com/j2se/1.3/docs/api/java/awt/Component.html
scroll down to the "action" method
click on it
hit "back" -- returns to top of page instead of to "action".
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313
Yup. I see that in 2002032608.

Evan: What you observe is bug 59774 "scroll position not remembered if URL
contains named anchor"

That has already been fixed in the latest nightlyies.
I still see the bug described by mrmazda twice (comments #23 and #29). Windows
and Linux, latest nightly.
Try http://www.providenceri.com/frame.html If you scroll down and click on one
of the links on the right, then go back to the first page, you'll end up at the top.
I've no idea what's causing it.
Jonas, you are seeing bug #47350 (as said before).

Dave, this works for me, using Mozilla 1.0rc1 on Windows 2000 (Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417).

Either it is a regression since then (this build is now nearly 2 weeks old) or
this behaviour is triggered as side-effect of other problems... What build are
you using?
Dave, what build, what platform, etc. FYI, the example you gave works fine in
1.0RC on Linux.
Oops... sorry.

Seeing it on 2002042412 and 2002042510 on Linux. Haven't tried any newer builds.
... Those being trunk builds.
Comment #44: Problem does occur for me on 2002051006 (rc2) on w2k (back button
redisplays page from top of page rather than from scroll position).
This still works-for-me (trying the advice of comment #44) using Mozilla 1.0
under Windows 2000 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0)
Gecko/20020530).

BTW, the link from comment #44 redirects now to
http://www.providenceri.com/home.html.

Perhaps it's still a problem on the trunk, but not on the 1.0 branch.
That's the same page I mentioned in #44. However, scroll position appears to be
restored correctly on 2002052908/Linux (haven't tested on anything from June yet).
Also works on 2002060504-trunk/Linux
Bugzilla lists are handled in bug 47350. In fact, all of the outstanding
testcases in comments are said to be handled by that bug. The URL for this bug
is dead. As many people have commented, this bug hasn't appeared in a long time.
Since this bug was reported, there was a fix made to the tree that took care of
the scroll position in Slashdot pages and elsewhere. I think that was bug
112564. That likely solved this bug. I'm not seeing this bug in 1.1alpha
2002060704. Resolving this bug as worksforme. 

Please reopen if there is a testcase not covered by an existing bug, such as bug
47350.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.