back button fails to restore horizontal scroll position




18 years ago
11 years ago


(Reporter: garsh, Assigned: john)




Firefox Tracking Flags

(Not tracked)



(2 attachments, 2 obsolete attachments)



18 years ago
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.

Comment 1

18 years ago
Seeing this on Win 95 too.

Augh! *wish... I... had... more... votes!*


18 years ago
OS: Linux → All

Comment 2

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 3

18 years ago
aack! stop doing this!
Resolution: WORKSFORME → ---

Comment 4

18 years ago
confirmed with 2001110903 win98 build although i believe it to be a dupe
Ever confirmed: true

Comment 5

18 years ago
> 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

Comment 6

18 years ago
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.

Comment 7

18 years ago
linux x86 2002011721

Still doesn't work for me on any of the sites I've tried.


17 years ago
Keywords: topembed

Comment 8

17 years ago
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

Comment 11

17 years ago
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. 

Comment 13

17 years ago
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.

Comment 14

17 years ago
Marking topembed-, if anyone thinks this is critical, please remove the - to 
Keywords: topembedtopembed-
Priority: -- → P1

Comment 15

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

Comment 16

17 years ago
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.

Comment 17

17 years ago
Posted file bug 133678 testcase
See bug 133678 for more info.

Comment 18

17 years ago
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.

Comment 19

17 years ago
When this problem occurred with the reload button,
immediately if window size changed, both scroll bar move to correct position.

Comment 20

17 years ago
I update my patch.
Please refer to "".

Comment 21

17 years ago
I'm seeing this with 2002100911.
Vertical scrollbar is not restored either, but i could'nt find any bug specific
to vertical scrolling.

Comment 22

17 years ago
Seeing this with 2002111808 on

Comment 23

17 years ago
Posted 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.

Comment 24

16 years ago
*** Bug 193498 has been marked as a duplicate of this bug. ***

Comment 25

16 years ago
Posted 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.

Comment 26

16 years ago
Posted 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


16 years ago
Attachment #122394 - Attachment is obsolete: true


16 years ago
Attachment #122395 - Flags: review?(jkeiser)

Comment 27

16 years ago
similar bug with another patch: Bug 226534

Comment 28

16 years ago
Worksforme with 20040112-trunk/Linux.

Comment 29

16 years ago
I guess it's fixed by a checkin from Bug 226534
Last Resolved: 18 years ago16 years ago
Resolution: --- → FIXED

Comment 30

16 years ago
It now works-for-me.
linux x86 2004011308


14 years ago
Attachment #122395 - Flags: review?(john)


11 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.