Closed Bug 485118 Opened 11 years ago Closed 10 years ago
vertical scrollbar thumb active area miscalculated
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:18.104.22.168) Gecko/2009021906 Firefox/3.0.7 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:22.214.171.124) 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.
You can visualize the problem by setting a border on the scrollbar's thumb (using the DOM Inspector).
Assignee: nobody → mstange
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.
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)
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.
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)
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 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.
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? → approval1.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.
(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
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 126.96.36.199, a=dveditz for release-drivers -- must land immediately or miss the boat
Attachment #406522 - Flags: approval188.8.131.52+
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 184.108.40.206pre) 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 220.127.116.11/18.104.22.168pre
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
(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 22.214.171.124pre) 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 126.96.36.199pre: 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 188.8.131.52/184.108.40.206pre → [tb3needed] landed on relbranch, verify on both 220.127.116.11/18.104.22.168pre
Thanks so much for getting this into 22.214.171.124.
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:126.96.36.199pre) 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.
Whiteboard: [tb3needed] landed on relbranch, verify on both 188.8.131.52/184.108.40.206pre → [tb3needed] landed on relbranch, verify on 220.127.116.11
Looks great with Shredder too. Verified fixed with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:18.104.22.168pre) Gecko/20091016 Shredder/3.0pre ID:20091016112627 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:22.214.171.124) Gecko/20091016 Firefox/3.5.4 ID:20091016081620
Whiteboard: [tb3needed] landed on relbranch, verify on 126.96.36.199 → [tb3needed]
My scroll bug is _not_ fixed: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:188.8.131.52pre) 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:184.108.40.206pre) > 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: approval220.127.116.11+
You need to log in before you can comment on or make changes to this bug.