Bug 93541 – [chromium] Move scrollbar pointer into WebScrollbarThemePainter

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Adrienne Walker]

[chromium] Move scrollbar pointer into WebScrollbarThemePainter

[Adrienne Walker]

Created attachment 157316 [details]
Patch

[Adrienne Walker]

I realize that the ownership model of the painter to the scrollbar is a little bit dodgy.  The painter needs a scrollbar but doesn't take a ref to it (largely because I couldn't put a RefPtr in the Platform API).

I can refactor this so that WebScrollbarThemePainter is an interface and then the WebScrollbarThemePainterImpl could hold onto a RefPtr<Scrollbar> if you think that's better.

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[James Robinson]

(In reply to comment #2)
> I realize that the ownership model of the painter to the scrollbar is a little bit dodgy.  The painter needs a scrollbar but doesn't take a ref to it (largely because I couldn't put a RefPtr in the Platform API).

WebPrivatePtr is the normal way we deal with this - it lets you take an opaque RefPtr, effectively.

> 
> I can refactor this so that WebScrollbarThemePainter is an interface and then the WebScrollbarThemePainterImpl could hold onto a RefPtr<Scrollbar> if you think that's better.

[James Robinson]

Comment on attachment 157316 [details]
Patch

To do the WebPrivatePtr thing you'd have to add an exported out-of-line destroy() function to drop the ref.  I think the ownership situation here is OK, though.

[WebKit Review Bot]

Comment on attachment 157316 [details]
Patch

Clearing flags on attachment: 157316

Committed r125130: <http://trac.webkit.org/changeset/125130>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.