Created attachment 546325 [details] [diff] [review]
If we want the right toolbar button appearance on 10.7, we can either add special cases to our CSS and use images to get the noise texture, or we can ask the system to draw the buttons.
This patch (on top of the one in bug 668195) implements -moz-appearance:toolbarbutton with CoreUI and contains almost all of the necessary CSS changes.
The only thing I haven't fixed up yet is the circle back button.
Ah, then I guess we don't need any patch in bug 553992?
I think we should take your patch in bug 553992 anyway since I don't know when this bug will be ready. We can always back it out again when I'm finished here.
This bug is blocked on bug 668195, and that needs some more theme fixup before it can land, and I don't know when I'll have time for that.
OK. Awesome work Markus :-)
OT: Markus, do you think CoreUI might be a viable option for drawing
scrollbars (instead of the HITheme API we're currently using)? And
might this allow us to support autohiding the scrollbars on OS X 10.7
(which the HITheme API currently doesn't support)?
(This is in regard to bug 636564.)
Created attachment 549331 [details] [diff] [review]
part 1, v1: add toolbarbutton rendering
Tabs and segmented toolbar buttons can be rendered with CoreUI with almost the same code, using widget types "tab" and "kCUIWidgetButtonSegmentedSCurve", respectively.
Created attachment 549334 [details] [diff] [review]
part 2, v1: inherit the open attribute on toolbarbutton[type=menu-button] dropmarkers
The CSS patch that will convert our custom toolbarbutton CSS to -moz-appearance: toolbarbutton will also set -moz-appearance: toolbarbutton on the dropmarker of a toolbarbutton[type="menu-button"]. Open menu button toolbarbuttons should have a pressed dropmarker, and inheriting open into the dropmarker is simpler than making widget code check the dropmarker's parent.
The other patch was backed out from inbound.