Closed Bug 99094 Opened 19 years ago Closed 17 years ago

back button fails to restore horizontal scroll position


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






(Reporter: garsh, Assigned: john)



(Keywords: topembed-)


(2 files, 2 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010909
BuildID:    2001-09-09-21

I see a handful of bug reports dealing with *vertical*
scroll position, but none about *horizontal* scroll position.

Horizontal position doesn't appear to be saved at all.

Reproducible: Always
Steps to Reproduce:
Go to any page that does not fit horizontally in your
browser's window (narrow your browser window if you have to).
Then scroll over to the right.
Then click on some link to go to another page.
Then hit the back button.

Actual Results:  The horizontal scroll bar is at the left.

Expected Results:  The horizontal scroll bar should be at the same position
as when you left the page.
Seeing this on Win 95 too.

Augh! *wish... I... had... more... votes!*
OS: Linux → All
Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.
Closed: 19 years ago
Resolution: --- → WORKSFORME
aack! stop doing this!
Resolution: WORKSFORME → ---
confirmed with 2001110903 win98 build although i believe it to be a dupe
Ever confirmed: true
> i believe it to be a dupe

I tried searching for such a bug before submitting this.
Can you provide a bug number?
Target Milestone: --- → mozilla1.0
The horizontal position is restored for me when going back to a horiz scrolled
page at  Using w98 build 2002011710.

However, it is not restored correctly when going forward on the same site.

Also, I had trouble with horiz restore going both back and forward within a frame.
linux x86 2002011721

Still doesn't work for me on any of the sites I've tried.
Keywords: topembed
I've tried it and apparantly this is some kind of race condition - the bug
started to WFM as soon as I inserted some debug statements and recompiled. But
with nightly 2002021806 (Linux-i686) I can still see it.
I see this working in one of the latest builds. Going forward/back or reload,
restores the scroll position to its previous place. claudius: can you  provide
some  input on this? Thanks.
*If* it is still a problem, it has to be fixed in layout. Giving  to jkeiser. 
Assignee: radha → jkeiser
The only case where I don't see it working is when there is a named anchor (a #
near the end of the URL), in which case it scrolls to the anchor.  That is a
separate bug.

Brad, Smyk, could you please give me some specific steps to reproduce, and
sites?  Maybe you and I are just surfing different sites and that's why I'm not
seeing it.

Radha, can you expound?  What makes you think this is layout?  (I'm only
slightly familiar with this side of stuff, so any info helps.)

Futuring until we get traction here.
Target Milestone: mozilla1.0 → Future
Jkeiser.  Session History and docshell are making the required calls to save and
restore layout frame state.  Iam also not sure that this problem is 100%
reproducible. Please see my earlier comment. If it is indeed a problem in
regular pages (not anchor ones) I  think it needs to be fixed where FrameState
is saved and restored.  If this is a problem only  with anchors,  then this can
be marked dupe of the other bug you have related to it. 
Ok, here we go.

Mozilla: 2002022121/Linux-i686.


1. Visit the site.
2. Narrow the window, so that the page does not fit and the horizontal scrollbar
3. Scroll page down and left, so that scrollers are not in their starting positions.
4. Click on any of those "wyswietl" links. It will take you to another page of
similar size.
5. Scroll this page, too, so that the scrollbars are changed.
6. Click "left arrow" to get back to previous page.
7. Vertical scrollbar is where you left it, but horizontal will probably be
reset to leftmost position.
8. Click "right arrow" to go forward to the page you just left.
9. Vertical scrollbar on this page is also reset.

Steps 7 and 9 are wrong, as both scrollbars should be where one left them.

Repeatability: from time to time.

As for Radha's reasons for reassigning this, I'd guess that race-condition that
I hinted to a few comments above is probably happening in
nsScrollBoxFrame::DoLayout(). Also, session history appears to handle this
properly, i.e. _both_ scrollbar's positions are indeed preserved and restored.

Marking topembed-, if anyone thinks this is critical, please remove the - to 
Keywords: topembedtopembed-
Priority: -- → P1
*** Bug 133678 has been marked as a duplicate of this bug. ***
Additional info:  via Bug 133678, this also happens on reloading a page, not
just with the back button.  Also, in the test case from that bug it was found
the vertical scroll bar would move up a very small amount if the window was
scrolled to the bottom right and then reloaded.  Testcase coming up.
Attached file bug 133678 testcase
See bug 133678 for more info.
Thanks for your response.
But I hope to test my patch

I want to explain that why patched this program.

--- layout/xul/base/src/	Wed Jan 23 11:53:02 2002
+++ layout/xul/base/src/nsScrollBoxFrame.cpp	Wed Mar 27 16:58:47 2002
@@ -833,8 +833,10 @@
         return NS_ERROR_FAILURE;
       nsCOMPtr<nsIScrollableView> scrollingView(do_QueryInterface(view));
-      if (scrollingView)
+      if (scrollingView) {
+        scrollingView->ScrollTo(x, y, 0);
         scrollingView->GetScrollPosition(mLastPos.x, mLastPos.y);
+      }
I could not confirme on build 2002031104 win98,
then I could not report to Bugzilla, 
butI could confirme on 0.9.8 and 0.9.9 compiled from source on NetBSD.

Testcase is Japanese URL "".

In case of this page, with the reload button, sometimes
the horizontal scroll bar and the vertical scroll bar move to left side and top
side, but sometimes can move to current position.

This patch could fix this problem.
When this problem occurred with the reload button,
immediately if window size changed, both scroll bar move to correct position.
I update my patch.
Please refer to "".
I'm seeing this with 2002100911.
Vertical scrollbar is not restored either, but i could'nt find any bug specific
to vertical scrolling.
Seeing this with 2002111808 on
Attached patch patch from bug 133678 (obsolete) — Splinter Review
The patch of bug 133678 is effective of mozilla-1.2.1.
The horizontal and vertical scroll bar of testcase was brought near by the
lower right, and it checked that a position did not change, when it reload.
*** Bug 193498 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — Splinter Review
I added a new patch.
Please refer to a following testcase of Bug 202837.

If a vertical scroll bar of table cell is scrolled and this page is loaded
again, it will return to the same scroll position by applying the patch of Bug
202837 too.
Attached patch patchSplinter Review
I added a new patch.
Please refer to a following testcase of Bug 202837.

If a vertical scroll bar of table cell is scrolled and this page is loaded
again, it will return to the same scroll position by applying the patch of Bug
202837 too.
Attachment #111898 - Attachment is obsolete: true
Attachment #122394 - Attachment is obsolete: true
Attachment #122395 - Flags: review?(jkeiser)
similar bug with another patch: Bug 226534
Depends on: 226534
Worksforme with 20040112-trunk/Linux.
I guess it's fixed by a checkin from Bug 226534
Closed: 19 years ago17 years ago
Resolution: --- → FIXED
It now works-for-me.
linux x86 2004011308
Attachment #122395 - Flags: review?(john)
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.