115758 - NS_THEME_SCROLLBAR* implementations (Mac)

Status: RESOLVED FIXED

(Core Graveyard :: Skinability, enhancement, P2)

Description

[Hixie (not reading bugmail)]

This covers the implementation of NS_THEME_SCROLLBAR, 
NS_THEME_SCROLLBAR_BUTTON, NS_THEME_SCROLLBAR_TRACK,
NS_THEME_SCROLLBAR_TRACK_START, NS_THEME_SCROLLBAR_TRACK_END,
NS_THEME_SCROLLBAR_THUMB and NS_THEME_SCROLLBAR_GRIPPER for XUL scrollbars on Mac.

Comment 1

[Mike Pinkerton (not reading bugmail)]

-> 099

Comment 2

[Hixie (not reading bugmail)]

Now NS_THEME_SCROLLBAR_BUTTON_UP, NS_THEME_SCROLLBAR_BUTTON_DOWN,
NS_THEME_SCROLLBAR_BUTTON_LEFT, NS_THEME_SCROLLBAR_BUTTON_RIGHT,
NS_THEME_SCROLLBAR_TRACK_HORIZONTAL, NS_THEME_SCROLLBAR_TRACK_VERTICAL,
NS_THEME_SCROLLBAR_THUMB_HORIZONTAL, NS_THEME_SCROLLBAR_THUMB_VERTICAL,
NS_THEME_SCROLLBAR_GRIPPER_HORIZONTAL and NS_THEME_SCROLLBAR_GRIPPER_VERTICAL.

Comment 3

[Mike Pinkerton (not reading bugmail)]

where did 099 go? was i asleep? was i dreaming? this is not my beautiful house.
this is not my beautiful wife.

Comment 4

[saari (gone)]

nsbeta1+ because it is important for theme rendering and embedding

Comment 5

[Mike Pinkerton (not reading bugmail)]

the current plan is to abandon the NS_THEME* for scrollbars on mac. the
appearance manager APIs don't match with the way gecko wants to draw the pieces.
As a result we get poor updating, overzealous painting, jiggling, and overall ick.

in its place, i plan on creating a native scrollbar frame, created from an XBL
binding with a new xul tag (something like <nativescrollbar>). It should be
pretty easy to hack into CSSFrameConstructor the code to create our new frame
when it sees the |natvescrollbar| tag. Our new frame will manage communication
between gecko and the nsIWidget scrollbar that is under the hood. Think of it as
a new kind of anonymous content ;)

scrollbar {
  -moz-binding:
url(chrome://global/content/bindings/myNativeScrollbar.xml#scrollbar);
}

<binding id="scrollbar">
  <content>
    <xul:nativescrollbar flex="1" inherits="curpos,maxpos,etc.etc."/>
  </content>
</binding>

The regular scrolling mechanics (ruled by nsGFXScrollFrame) use nsIBox to handle
layout and sizing, so our frame will have to implement that. nsGFXSF gets the
position from the scrollbar's content node and manipulates it directly. It's a
document observer so it will be notified when those attributes change. All our
scrollframe has to do is to make sure to tweak those attributes.

For outliner, we have to use nsIScrollbarMediator to tell the outliner when and
how to scroll. Again, the outliner uses the content node's attributes to move
the scrollbar.

It'll be a lot of work, but in the end i think it will be worth it. We'll have
native scrollbars, which will also make os9's funky scrollwheel support happy.

Comment 6

[Mike Pinkerton (not reading bugmail)]

fixed with native widgets in 121440