99094 - back button fails to restore horizontal scroll position

Status: RESOLVED FIXED

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

Description

[Brad Garcia]

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

[James Paige]

Seeing this on Win 95 too.

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

Comment 2

[Keyser Sose]

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.

Comment 3

[Claudius Gayle]

aack! stop doing this!

Comment 4

[Claudius Gayle]

confirmed with 2001110903 win98 build although i believe it to be a dupe

Comment 5

[Brad Garcia]

> i believe it to be a dupe

I tried searching for such a bug before submitting this.
Can you provide a bug number?

Comment 6

[djk]

The horizontal position is restored for me when going back to a horiz scrolled
page at usps.com.  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

[Brad Garcia]

linux x86 2002011721

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

Comment 8

[Miloslaw Smyk]

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.

Comment 9

[Radha on family leave (not reading bugmail)]

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.

Comment 10

[Radha on family leave (not reading bugmail)]

*If* it is still a problem, it has to be fixed in layout. Giving  to jkeiser. 

Comment 11

[John Keiser (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.

Comment 12

[Radha on family leave (not reading bugmail)]

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

[Miloslaw Smyk]

Ok, here we go.

Mozilla: 2002022121/Linux-i686.
URL: http://amiga.com.pl/

Steps:

1. Visit the site.
2. Narrow the window, so that the page does not fit and the horizontal scrollbar
appears.
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

[karnaze (gone)]

Marking topembed-, if anyone thinks this is critical, please remove the - to 
renominate.

Comment 15

[Todd Cohn]

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

Comment 16

[Todd Cohn]

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

[Todd Cohn]

Attachment: bug 133678 testcase

See bug 133678 for more info.

Comment 18

[Hideo Saito]

Thanks for your response.
But I hope to test my patch
http://bugzilla.mozilla.org/attachment.cgi?id=76382&action=view.

I want to explain that why patched this program.

--- layout/xul/base/src/nsScrollBoxFrame.cpp.org	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 "http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2002".

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

[Hideo Saito]

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

Comment 20

[Hideo Saito]

I update my patch.
Please refer to "http://bugzilla.mozilla.org/show_bug.cgi?id=133678".

Comment 21

[Hector Fabio Meza]

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

[Sam Rowe]

Seeing this with 2002111808 on http://opie.handhelds.org/screenshots/gallery/

Comment 23

[Hideo Saito]

Attachment: patch from bug 133678

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

[R.K.Aa.]

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

Comment 25

[Hideo Saito]

Attachment: patch

I added a new patch.
Please refer to a following testcase of Bug 202837.

http://www.w3.org/People/mimasa/test/xhtml/media-types/results

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

[Hideo Saito]

Attachment: patch

I added a new patch.
Please refer to a following testcase of Bug 202837.

http://www.w3.org/People/mimasa/test/xhtml/media-types/results

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 27

[Oleg Sidletskiy]

similar bug with another patch: Bug 226534

Comment 28

[Hideo Oshima]

Worksforme with 20040112-trunk/Linux.

Comment 29

[Oleg Sidletskiy]

I guess it's fixed by a checkin from Bug 226534

Comment 30

[Brad Garcia]

Agreed.
It now works-for-me.
linux x86 2004011308