448704 - Eliminate <gripper> as an independent element

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Kai Liu]

Attachment: patch

Currently, scrollbar thumbs are structured such that there is a <gripper> element (which draws the small set of decorative lines) residing within the <thumb>.  I would like to get rid of <gripper> and have the gripper be drawn as a part of <thumb> instead of as a separate independent element.  I can't really see a reason for it to exist as a separate element.

1) Mac scrollbars have no grippers, and on GTK, the native theme rendering draws the gripper as a part of the thumb, and the separate <gripper> element is unused.  Windows is the only place where the gripper is handled as a separate element.  I would like to see the three platforms be consistent here, and we can do that by getting rid of <gripper> as an independent element.

2) This will allow us to properly fix bug 424694, and it would've prevented bug 439274.

3) This will make the Windows behavior more native, where the thumb can shrink below a certain size and the grip will disappear--doing that before this would not have been very feasible.

4) If a third-party theme wants the ability to customize the gripper (how many themes even bother with doing that?), they can still do so with a background image applied to the thumb.

(Vlad, you can review toolkit changes, right?  You're listed as a toolkit peer...)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 331877 [details] [diff] [review]
patch

This looks fine to me, so r=dbaron.

But I think you should get Neil Deakin, or some other XUL owner/peer, to review this as well.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 331877 [details] [diff] [review]
patch

Looks fine to me as well, but I think you need a XUL sr since you're removing a XUL element..

Comment 3

[Kai Liu]

Comment on attachment 331877 [details] [diff] [review]
patch

Ah, my apologies; I am not familiar with who is in charge of what.

Comment 4

[Neil Deakin]

Comment on attachment 331877 [details] [diff] [review]
patch

Looks OK

Comment 5

[Kai Liu]

I need to remember to document this in the things-affecting-theme-developers page for 3.1 if/when this lands.

Comment 6

[[e-mail]]

(In reply to comment #0)
>4) If a third-party theme wants the ability to customize the gripper (how many
>themes even bother with doing that?), they can still do so with a background
>image applied to the thumb.
Since this was only implemented to support native theming, third-party themes would probably already be using a background image applied to the thumb.

(From update of attachment 331877 [details] [diff] [review])
>+  <binding id="thumb" extends="xul:button" />
Why the extra space before the /> ?

Comment 7

[Dão Gottwald [:dao]]

http://hg.mozilla.org/index.cgi/mozilla-central/rev/888b724a1b90

Comment 8

[Kai Liu]

Sorry; I haven't been around the past few weeks, so I'm just doing some catch-up right now...

(In reply to comment #6)
> Since this was only implemented to support native theming, third-party themes
> would probably already be using a background image applied to the thumb.
> 
That's a good point.  I haven't had a chance to do a complete survey of third-party themes, but after taking a random sampling, I noticed that the gripper is almost never used by third party theme authors.  The one theme that I sampled that did use the gripper did not use a textured thumb element and only used borders for the styling of the thumb.  I personally think that it's still a worthwhile tradeoff, but if people feel strongly otherwise, we could back this out.

> Why the extra space before the /> ?
> 
There is no particular reason for the space; I did not think to check what the prevalent style was with respect to a spaces before />, so mea culpa.  I do not have hg access, so if someone would like to do a spacing nit fix for this, that'd be great.