Closed Bug 485118 Opened 11 years ago Closed 10 years ago

vertical scrollbar thumb active area miscalculated

Categories

(Toolkit :: XUL Widgets, defect)

All
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta2-fixed
status1.9.1 --- .4-fixed

People

(Reporter: kwiniec, Assigned: mstange)

References

Details

(Keywords: verified1.9.1, verified1.9.2, Whiteboard: [tb3needed])

Attachments

(3 files, 1 obsolete file)

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.
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.
> 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.
Attached image problem illustration
You can visualize the problem by setting a border on the scrollbar's thumb (using the DOM Inspector).
Assignee: nobody → mstange
Blocks: 370439
Status: UNCONFIRMED → NEW
Component: Bookmarks & History → XUL Widgets
Ever confirmed: true
Product: Firefox → Toolkit
QA Contact: bookmarks → xul.widgets
Hardware: x86 → All
Version: unspecified → Trunk
(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.
Duplicate of this bug: 476701
Duplicate of this bug: 475039
Flags: wanted-thunderbird3?
Duplicate of this bug: 501211
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.
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.
It seems to be fixed in TB3.0b3
No, it doesn't.  It just doesn't happen 100% of the time.  (Which was the case in 3.0b2, too.)
You are right. It is doing it again. I think this really needs to be fixed before the 3.0 release.
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)
Duplicate of this bug: 515058
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.
This is still a problem on beta 4 if the inbox is too big. And the new combined inbox makes this worse.
Status: NEW → ASSIGNED
Duplicate of this bug: 519971
Attached patch v1 (obsolete) — Splinter Review
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?
Attachment #404149 - Flags: review?(joshmoz)
Attachment #404149 - Flags: review?(joshmoz) → review+
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.
Attached patch v2Splinter Review
Hardcoding.
Attachment #404149 - Attachment is obsolete: true
Attachment #404745 - Flags: review?(joshmoz)
Attachment #404745 - Flags: review?(joshmoz) → review+
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.
http://hg.mozilla.org/mozilla-central/rev/b8529fc47060
Severity: minor → normal
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
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.
Attachment #404745 - Flags: approval1.9.2?
Attachment #404745 - Flags: approval1.9.1.5?
Whiteboard: [tb3needs]
Attachment #404745 - Flags: approval1.9.2? → approval1.9.2+
Duplicate of this bug: 472476
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.
(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
Flags: wanted-thunderbird3?
FWIW, this is a super annoying bug with the mac version of TB.
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
Attachment #406522 - Flags: approval1.9.1.4+
Attachment #404745 - Flags: approval1.9.1.5?
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.
Whiteboard: [tb3needs] → [tb3needs] landed on relbranch, verify on both 1.9.1.4/1.9.1.5pre
Attachment #406522 - Flags: approval1.9.1.5+
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.
Status: RESOLVED → VERIFIED
Flags: in-testsuite+
(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
Whiteboard: [tb3needs] landed on relbranch, verify on both 1.9.1.4/1.9.1.5pre → [tb3needed] landed on relbranch, verify on both 1.9.1.4/1.9.1.5pre
Thanks so much for getting this into 1.9.1.4.
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.
Keywords: verified1.9.2
Whiteboard: [tb3needed] landed on relbranch, verify on both 1.9.1.4/1.9.1.5pre → [tb3needed] landed on relbranch, verify on 1.9.1.4
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
Keywords: verified1.9.1
Whiteboard: [tb3needed] landed on relbranch, verify on 1.9.1.4 → [tb3needed]
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.
(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.
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.
(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.
Attachment #406522 - Flags: approval1.9.1.6+
You need to log in before you can comment on or make changes to this bug.