485118 - vertical scrollbar thumb active area miscalculated

Status: VERIFIED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Ken Winiecki, Jr.]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

For at least some vertical scrollbars in 3.0.x, the height of the thumb active area decreases faster than the height of the thumb itself with increasing data.  Additionally, the vertical position of the active area within the thumb is proportional to the position of the thumb within the scrollbar.

Reproducible: Always




With 2000 bookmarks, the thumb active area height is about 10% of the thumb height in the bookmarks sidebar and the right pane of the bookmarks manager (Library window).  And when the thumb is at the [top/middle/bottom] of the scrollbar, the active area is at the [top/middle/bottom] of the thumb, etc.

2.0.0.x did not have this bug.

Comment 1

[Marco Bonardo [:mak]]

is this only a bookmarks Library issue or do you see the problem in other windows too? Also, a screenshot with some description would help.
Sound more like a widget/layout bug than a bookmarks one to me.

Comment 2

[Ken Winiecki, Jr.]

> is this only a bookmarks Library issue or do you see the problem in
> other windows too?

It always occurs in: (1) Library window right pane, and (2) main window bookmarks sidebar pane.  It never occurs in: (1) main window browser pane, (2) view source window, or (3) textarea HTML element.  Those five are the only windows I figured out how to get 2000 lines in to test; I will happily test any other ideas you have.

> Also, a screenshot with some description would help.

I will also happily do this if you can tell me how it could help, because the problem does not seem to have any visual indications.  The window looks exactly as it should; the mis-sized active area of the scrollbar thumb is invisible to everything but the mouse.  A movie of me clicking around inside the visible thumb where the invisible active area should be and not being able to find it would not seem to yield any more information.

That is another way to about it, as 2 thumbs superimposed:  a visible one only you can see, and an invisible one only the mouse can see.  The visible thumb looks as you expect, a fine mouse target.  But when there are a lot of lines to scroll, the invisble thumb is much shorter than, and not centered within, the visible thumb, making a poor mouse target.  And seemingly only on the windows designed to display bookmarks.

Comment 3

[Markus Stange [:mstange]]

Attachment: problem illustration

You can visualize the problem by setting a border on the scrollbar's thumb (using the DOM Inspector).

Comment 4

[Markus Stange [:mstange]]

(In reply to comment #2)
> > is this only a bookmarks Library issue or do you see the problem in
> > other windows too?
> 
> It always occurs in: (1) Library window right pane, and (2) main window
> bookmarks sidebar pane.

These are both XUL trees which use an XBL scrollbar.

> It never occurs in: (1) main window browser pane, (2)
> view source window, or (3) textarea HTML element.

The scrollbars here are created in a different way, though I'm not sure how exactly that works.

So it looks like XBL scrollbars need some min-height fixup, presumably in pinstripe/global/nativescrollbars.css.

Comment 8

[Munroe]

I found this bug by first finding Bug 476701.  As it hasn't been mention in this bug yet, I would like to add the inbox in the latest nightly of TB3 exhibiting this problem (with about 4k messages in the inbox).  I am seeing this behavior all the time, not just in the specific conditions mentioned in the above bug number.  It makes it extremely difficult to maneuver within the inbox.

Comment 9

[Markus Stange [:mstange]]

A quick workaround is to activate the "scroll to click" behaviour in the system appearance preferences, or alternatively, holding the option key while clicking in the scrollbar.

Comment 10

[James Rome]

It seems to be fixed in TB3.0b3

Comment 11

[Braden]

No, it doesn't.  It just doesn't happen 100% of the time.  (Which was the case in 3.0b2, too.)

Comment 12

[James Rome]

You are right. It is doing it again. I think this really needs to be fixed before the 3.0 release.

Comment 13

[Munroe]

I would like to assert this bug fixed in TB3, the latest nightly no longer exhibits this behavior on my system (OS X 10.4.11)

Comment 15

[mozilla]

If my bug 515058 is really a duplicate of this then I assert _NOT FIXED_ in the latest nightly.  My system is running Snow Leopard 10.6.

Note that this behaviour is intermittent.  I've been unable to confirm what triggers it.

Comment 16

[James Rome]

This is still a problem on beta 4 if the inbox is too big. And the new combined inbox makes this worse.

Comment 18

[Markus Stange [:mstange]]

Attachment: v1

At the time the min size of the scrollbar thumb was requested, the scrollbar wasn't set up yet, so the scrollbarRect was still empty. This caused us to return a zero minimum size for the thumb.
This patch changes the code to not depend on the scrollbar's rect. Instead, it gets the thumb size for a 100x100 scrollbar with a large max value and a tiny viewsize.

Alternatively, since we're already hardcoding thumbAdjust, we could just hardcode the whole value (19 for small scrollbars and 22 for large ones). Do we want to do that?

Comment 19

[Josh Aas]

I'm also fine with hard-coding. I don't think we lose anything worthwhile by doing that and it is faster. If you want to do that just post another patch and I'll review again. Thanks.

Comment 20

[Markus Stange [:mstange]]

Attachment: v2

Hardcoding.

Comment 21

[Josh Aas]

Comment on attachment 404745 [details] [diff] [review]
v2

>+      PRBool isSmall = scrollbarFrame->GetStyleDisplay()->mAppearance == NS_THEME_SCROLLBAR_SMALL;
>+      PRBool isHorizontal = (aWidgetType == NS_THEME_SCROLLBAR_THUMB_HORIZONTAL);

Please put () around the "==" comparison for the first PRBool the same way you did for the second.

Comment 22

[Markus Stange [:mstange]]

http://hg.mozilla.org/mozilla-central/rev/b8529fc47060

Comment 23

[Markus Stange [:mstange]]

Comment on attachment 404745 [details] [diff] [review]
v2

I'd like this on the branches, especially for Thunderbird. High reward, very low risk, has test.

Comment 25

[Mark Banner (:standard8)]

Attachment: Patch as checked into 1.9.2

I've just pushed this to 1.9.2, there was a little bit of bitrot because bug 514745 hasn't landed on the branch.

However I investigated the change and in the affected place it was only a change to a parameter being passed to a function and the patch was removing the function call (amongst other things). I also verified that Firefox build and passed the chrome test included in the patch.

Comment 26

[Mark Banner (:standard8)]

(In reply to comment #25)
> Created an attachment (id=406522) [details]
> Patch as checked into 1.9.2
> 
> I've just pushed this to 1.9.2, there was a little bit of bitrot because bug
> 514745 hasn't landed on the branch.

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5a1e686d24b2

Comment 27

[David :Bienvenu]

FWIW, this is a super annoying bug with the mac version of TB.

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 406522 [details] [diff] [review]
Patch as checked into 1.9.2

Approved for 1.9.1.4, a=dveditz for release-drivers -- must land immediately or miss the boat

Comment 29

[Daniel Veditz [:dveditz]]

Comment on attachment 406522 [details] [diff] [review]
Patch as checked into 1.9.2

This needs to land on both the 1.9.1 branch (which is now 1.9.1.5pre) and GECKO1914_20091006_RELBRANCH

Set the status1.9.1 field to .4-fixed and we'll figure out how to track double/relbranch landings later.

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091015 Minefield/3.7a1pre ID:20091015030945

For testing I have used the automated test which has been checked-in too.

Comment 31

[Mark Banner (:standard8)]

(In reply to comment #29)
> (From update of attachment 406522 [details] [diff] [review])
> This needs to land on both the 1.9.1 branch (which is now 1.9.1.5pre) and
> GECKO1914_20091006_RELBRANCH
> 
> Set the status1.9.1 field to .4-fixed and we'll figure out how to track
> double/relbranch landings later.

Checked in to 1.9.1.5pre: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cc9b96388991

Checked into GECKO1914_20091006_RELBRANCH: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3507a87dff89

Comment 32

[Dan Mosedale (:dmosedale, :dmose)]

Thanks so much for getting this into 1.9.1.4.

Comment 33

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Verified fixed with the following builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091016 Namoroka/3.6b2pre ID:20091016042840

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5pre) Gecko/20091016 Shiretoko/3.5.5pre ID:20091016030647

Once the build 3 and todays Shredder builds are ready I will do another test with those builds.

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Looks great with Shredder too. Verified fixed with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5pre) Gecko/20091016 Shredder/3.0pre ID:20091016112627

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 ID:20091016081620

Comment 35

[mozilla]

My scroll bug is _not_ fixed:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5pre) Gecko/20091015 Shredder/3.0pre

On my (very large) Inbox I can't scroll the message list by grabbing the scroll thumb.  Using the scroll wheel, or clicking the up/down buttons, or clicking either side of the thumb all work.  But if I click on the thumb and move the mouse it resolutely stays where it is.

When I start Shredder it's fine.  It appears to be triggered when I change to a different folder and then back to my Inbox.

Comment 36

[Mark Banner (:standard8)]

(In reply to comment #35)
> My scroll bug is _not_ fixed:
> 
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5pre)
> Gecko/20091015 Shredder/3.0pre

Your build (15th October) is from before this patch was checked in (it got checked in on that day but not before the nightly was generated). You need a build with Gecko/20091016 or later in its user agent.

Comment 37

[mozilla]

Ah, yes, so it is.  I'll try again tomorrow once Shredder offers me the next update.   I had just checked for new versions and the auto-updater said there weren't anyway.

Comment 38

[Mark Banner (:standard8)]

(In reply to comment #37)
> Ah, yes, so it is.  I'll try again tomorrow once Shredder offers me the next
> update.   I had just checked for new versions and the auto-updater said there
> weren't anyway.

I've just filed bug 523093 as our (MoMo) update server appears to be broken.