201815 - Going back to the previous web page sets vertical scrollbar [scroll bar] elevator in the wrong position [at top] using Classic theme

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[jt.marsh]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030409 Chimera/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030409 Chimera/0.7+

Go to www.lacie.com.
Scroll to the bottom of the page and click on any link.
Click the back button to return to the previous page.

Camino show the bottom of the page, but the scroll bar is at the top.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Expected Results:  
Scrollbar should be place at the bottom.

Comment 1

[Greg K.]

Confirmed using Camino/2003-04-08-05-trunk and FizzillaMach/2003-04-11-08-trunk.
Reassigning to Browser, XP Toolkit/Widgets, and adding qawanted as more triage
is needed.

Comment 2

[Greg K.]

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

Comment 3

[kguru]

Nominating as blocker for 1.4beta as it significantly impacts browser functionality

Comment 4

[Asa Dotzler [:asa]]

Is this a general problem with all pages or specific to the lacie page? 

Comment 5

[Nathan Hamblen]

It's a general problem. I see it in Camino consistantly.

Comment 6

[Greg K.]

Nathan, can you give another example or two? It doesn't seem to happen using
<http://www.mozilla.org/> using FizzillaMach/2003-04-22-08-trunk and
Camino/2003-04-22-05.

Comment 7

[Nathan Hamblen]

Seems to have been fixed -- WFM in lastest nightly.

Comment 8

[Greg K.]

Really? FizzillaMach/2003-04-22-08-trunk exhibits the problem using
<http://www.lacie.com/>. Are you using a 4/24 build, Nathan?

I wonder what could have fixed it.

Comment 9

[kguru]

Still broken as of build 2003042408 on <http://www.lacie.com/>

Comment 10

[Nathan Hamblen]

All I know is that last week I started seeing "this" bug in Camino, except that
it was for any page. I never even tried the lacie page. After comment #6 I
downloaded the 4/24 Camino build and stopped seeing it for any page, including
the lacie page. Now, inexplicably, the same old build that had the problem
behavior before is doing just fine. I'm stumped. If I start seeing the bug again
with a fresh build I'll report back here.

Comment 11

[Mike Pinkerton (not reading bugmail)]

wfm on my most recent camino build, from a couple days ago (unsure of exact date)

Comment 12

[Asa Dotzler [:asa]]

I can't repro on the latest Moz or Camino build at lacie or any of a handful of
other pages I tested. blocking1.4b-

Comment 13

[Nathan Hamblen]

It depends on something in the user profile. I was just now seeing it with
www.mozilla.org (of all places) and about 90% of the sites I would visit. Seemed
pretty random, but once a site showed the error it would do it consistently,
even between restarts and different Camino builds. I trashed my profile and now
everything is fine. But for how long...?

Comment 14

[Greg K.]

Attachment: Screen capture demonstrating the problem using FizzillaMach/2003-04-25-08-trunk

Still reproducible using FizzillaMach/2003-04-25-08-trunk. In this screenshot,
notice that the scroll elevator is wrongly at top of the bar.

Also notice that when the window is resized during this condition, detritus is
left behind.

(I'm using Pinstripe theme, based on Classic. Could this be Classic-only?)

Comment 15

[kguru]

I tried using the Modern theme in today's nightly MachO build and could not
reproduce it.  With Classic I can.  Camino also still has the bug.

Comment 16

[Greg K.]

Confirmed that it's only a bug using Classic theme.

Comment 17

[Neil Lee [:neilio]]

Confirming this is still happening with Camino Build ID: 2003042605.

Comment 18

[Greg K.]

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

Comment 19

[Greg K.]

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

Comment 20

[Greg K.]

Revising summary; we're actually talking about the scroll elevator being in the
wrong position, not the bar.

Comment 21

[Greg K.]

Note that this will also occur with scrolling form lists on a page.

1. Access the Bugzilla Query page
2. Scroll Product list to the bottom, showing Webtools
3. Click the "Component" link
4. Go back

Note that Product still shows the bottom of the list, but the elevator is at the
top of the list.

Comment 22

[Greg K.]

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

Comment 23

[Greg K.]

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

Comment 24

[Adam Masri]

Added "scrollbar" to summary to make this bug easier to find.

Comment 25

[Greg K.]

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

Comment 26

[Chris Casciano]

re: comment 16: this also occurs using the pinstripe theme (not a total surprise)

Comment 27

[Chris Casciano]

adding regression keyword

Going through Mozilla nightlies I have on hand I have a guestimate on this between:

2003040608 - good
2003041008 - bad
7 nightles since then all bad

I'd have to pull some moz builds to narrow it down anymore. As some parralel
data (and curiously different data then what has been reported by others here) I
can't repro this immediately the leclie example in Camino - 9 nightlies evenly
spread between 040905 & 050904 - and I flip between the 2 so often I'm can't say
for sure which of the 2 i've seen this in when.

Comment 28

[Greg K.]

WFM in FizzillaMach/2003-04-08-09-trunk, created at 5:23 AM. Chris, what was the
creation time of the 2003041008 build?

Comment 29

[Chris Casciano]

getinfo shows a create date on 041008 of apr 10, 2003, 8:25 AM [i'm on the east
coast if that matters]

Comment 30

[Greg K.]

Check-ins during that time:
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=04%2F08%2F2003+05%3A23%3A00&maxdate=04%2F10%2F2003+05%3A25%3A00&cvsroot=%2Fcvsroot>.

Bug 126263, bug 201299, and bug 201300 mention scrolling.

Comment 31

[Greg K.]

CCing Robert. Robert, could any of your bugs mentioned in my comment 30 have
caused this bug?

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not sure what's going on exactly, but it's quite likely that bug 201300
interfered with the way native scrollbars work in Camino. Bug 201300 changed the
way scrollposition attribute changes are routed to nsGfxScrollFrame, to avoid
using a document listener.

Comment 33

[Chris Casciano]

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

Comment 34

[Greg K.]

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

Comment 35

[Chris Casciano]

nominating blocking 1.4... I know there isn't a proposed patch yet, but I don't
think this should make it into the stable branch if it can be helped.

Comment 36

[Greg K.]

If nobody has time to fix this, could bug 201300 simply be backed out for 1.4 if
indeed it's the cause?

Comment 37

[Chris Casciano]

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

Comment 38

[Joseph Delaney]

Another symptom that has not been mentioned here is when the page is in this
state, if you click the up or down scroll arrows or try to drag the scroll
elevator, the page will jump to the top. However, using the up/down arrows on
the keyboard has the opposite effect of causing the elevator to jump to reflect
the actual scroll position of the page. 

It's also intermittent. I see this problem frequently but had trouble getting it
to happen this morning until I went to the lacie page mentioned here. I had gone
to several long pages sequentially without triggering the bug, when I went to
the lacie page going back through the entire history of pages showed the symptom
where it had not shown before, including pages in different tabs. 

Comment 39

[Mike Pinkerton (not reading bugmail)]

this happens in camino too. it's very annoying and a regression from the branch.

Comment 40

[Brian Ryner (not reading)]

The NativeScrollbarFrame is not getting any AttributeChanged notification for
'curpos' when you go back to the previous page.  roc, any idea why that would be?

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Like I said, look at the patch in bug 201300. We got rid of the document
listener in nsGfxScrollFrame and instead routed attribute changed notifications
to nsGfxScrollFrame by using the frame attribute change notification and having
that do a custom callback on nsGfxScrollFrame. I'm not sure how this could have
broken your native scrollbars but I bet that is it.

Comment 42

[Greg K.]

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

Comment 43

[Brian Ryner (not reading)]

Attachment: fix

The problem is that the 'curpos' attribute is already set on the content node
at the time the NativeScrollbarFrame is created, so there is no attribute
change notification for it.  I've fixed it here by checking the value at the
end of Hookup() and propagating it to the native scrollbar if it's set to a
non-zero value.

We could do the same for maxpos/pageincrement/increment, but those seem to
always be set later and generate attribute change notifications.  Should we do
it anyway for consistency?  Or, instead, should we simply note that curpos is
present and wait to notify the scrollbar until after we find out maxpos? (which
would help the native scrollbar code do better bounds checking)

Comment 44

[Brian Ryner (not reading)]

Comment on attachment 124057 [details] [diff] [review]
fix

Looking for input... pink, what do you think?

Comment 45

[Chris Casciano]

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

Comment 46

[Chris Casciano]

updating summary to make this a tad easier to find... sorry for the spam

Comment 47

[Samir Gehani]

adt: nsbeta1+/adt2

Brian has a fix so reassigning.

Comment 48

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 124057 [details] [diff] [review]
fix

seems fragile, but prolly the best we can get.

Comment 49

[Chris Casciano]

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

Comment 50

[Brian Ryner (not reading)]

fix checked in.

Comment 51

[Asa Dotzler [:asa]]

Comment on attachment 124057 [details] [diff] [review]
fix

Is this something we want for the branch? What's the risk?

Comment 52

[Paul Wyskoczka]

a=adt Please check into the Mozilla 1.4 branch after getting drivers approval
and add the keyword fixed1.4

Comment 53

[Brian Ryner (not reading)]

fix checked in on MOZILLA_1_4_BRANCH.

Comment 54

[Paul Wyskoczka]

Verified on the branch in build 2003060905

Marking verified1.4

Comment 55

[Asa Dotzler [:asa]]

mozilla1.4 shipped. unsetting blocking1.4 request.