Bug 109064 – [chromium] Default scrollbar theme should be shared with CC compositor.

• Component: New Bugs
• Status: RESOLVED WONTFIX

[W. James MacLean]

[chromium] Default scrollbar theme should be shared with CC compositor.

[W. James MacLean]

Created attachment 186873 [details]
Patch

[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]

This seems strange.  For WebKit-created scrollbars, we want to make sure the theming matches so it looks exactly like a WebKit rendered scrollbars.  For scrollbars that aren't created and owned by WebKit, why would you want to use the same theme?

[W. James MacLean]

(In reply to comment #3)
> This seems strange.  For WebKit-created scrollbars, we want to make sure the theming matches so it looks exactly like a WebKit rendered scrollbars.  For scrollbars that aren't created and owned by WebKit, why would you want to use the same theme?

We don't need the scrollbars to look identical to WebKit ones, so we have a custom painter.

Two responses here:

1) We want the ability to know if the main-frame scrollbars (created by WebKit) will be overlay or not so we will know wether pinch-zoom scrollbars are needed (non-overlay => yes) or not (overlay => no) (here we just plumb through the boolean value).

2) We want to be able to render the pinch-zoom scrollbars with the WebKit default theme geometry, *and* to create a ScrollbarLayer we need a WebScrollbarThemeGeometry* that is built from a theme geometry, which in this case is the default theme geometry.

This is my understanding of the approach you described, based on our conversation from two weeks ago (getting at the theme pointer and plumbing it through to CC).

[W. James MacLean]

(In reply to comment #3)
> This seems strange.  For WebKit-created scrollbars, we want to make sure the theming matches so it looks exactly like a WebKit rendered scrollbars.  For scrollbars that aren't created and owned by WebKit, why would you want to use the same theme?

BTW, this CL is the companion to https://codereview.chromium.org/11550035/

[James Robinson]

(In reply to comment #4)
> (In reply to comment #3)
> > This seems strange.  For WebKit-created scrollbars, we want to make sure the theming matches so it looks exactly like a WebKit rendered scrollbars.  For scrollbars that aren't created and owned by WebKit, why would you want to use the same theme?
> 
> We don't need the scrollbars to look identical to WebKit ones, so we have a custom painter.
> 
> Two responses here:
> 
> 1) We want the ability to know if the main-frame scrollbars (created by WebKit) will be overlay or not so we will know wether pinch-zoom scrollbars are needed (non-overlay => yes) or not (overlay => no) (here we just plumb through the boolean value).
> 

How does the default theme make the determination to be overlay or not?  If you want to mirror the setting I think you should look at where it's coming from.

What would it mean to have a "non-overlay pinch-zoom scrollbar"?  Pinch-zoom scrollbars can't take layout space (by definition), so doesn't that mean they are always overlay?


> 2) We want to be able to render the pinch-zoom scrollbars with the WebKit default theme geometry

Why?  Why is WebKit's default theme geometry the geometry you want for pinch-zoom scrollbars, which aren't WebKit-related things?  They don't seem related to me.

[W. James MacLean]

(In reply to comment #6)
>
> 
> How does the default theme make the determination to be overlay or not?  If you want to mirror the setting I think you should look at where it's coming from.

It's set as an override to a virtual function. At present. ScrollbarThemeChromium (Default?) always says 'false' for usesOverlayScrollbars() whereas ScrollbarThemeChromiumAndroid always says 'true'. I figured if I plumbed the value, I'd pick up whichever was in use without having to assume anything other than constancy for a given platform (e.g. ScrollbarTheme won't give a different answer on subsequent calls).
 
> What would it mean to have a "non-overlay pinch-zoom scrollbar"?  Pinch-zoom scrollbars can't take layout space (by definition), so doesn't that mean they are always overlay?

Pinch zoom scrollbars are always overlay. *But* they are only needed *if* the mainframe scrollbars are non-overlay, and they are not needed if the mainframe scrollbars are overlay.

> 
> > 2) We want to be able to render the pinch-zoom scrollbars with the WebKit default theme geometry
> 
> Why?  Why is WebKit's default theme geometry the geometry you want for pinch-zoom scrollbars, which aren't WebKit-related things?  They don't seem related to me.

No, they're not related, but the WebKit theme suffices just fine for pinch-zoom scrollbars, so why not use it?

This is a challenging conversation to have on the bug ... should we do this by VC tomorrow instead? Obviously I didn't understand what you wanted, so it would help me to get some clarification if we could talk in real time.

[James Robinson]

Comment on attachment 186873 [details]
Patch

Let's do that before proceeding.  I'm out the rest of this week.