Bug 72551 – When the recommended scrollbar style changes, WKView's tracking options should adjust accordingly

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Beth Dakin]

https://bugs.webkit.org/show_bug.cgi?id=72400 and http://trac.webkit.org/changeset/100483 made it so a WKView tracks the mouse all the time when the recommended scrollbar style is the legacy style at the time the WKView is created. The tracking options should also be updated whenever the recommended scrollbar style changes after the view has been created.

<rdar://problem/10409328>

[Beth Dakin]

Created attachment 115454 [details]
Patch

[Darin Adler]

Comment on attachment 115454 [details]
Patch 

View in context: https://bugs.webkit.org/attachment.cgi?id=115454&action=review

> Source/WebCore/platform/ScrollView.cpp:966
> +void ScrollView::scrollbarStyleChanged(int newStyle, bool forceUpdate)
>  {
> +    UNUSED_PARAM(newStyle);

Normally we omit the argument name or comment it out rather than using UNUSED_PARAM.

> Source/WebKit2/WebProcess/Plugins/PDF/BuiltInPDFView.cpp:677
> +void BuiltInPDFView::scrollbarStyleChanged(int newStyle, bool forceUpdate)
>  {
> +    UNUSED_PARAM(newStyle);

Same comment here.

[Beth Dakin]

Thanks Darin! I changed those two spots. Committed with revision 100826.

[Beth Dakin]

This got rolled out because of a Chromium build bustage (see https://bugs.webkit.org/show_bug.cgi?id=72786). I will be re-committing momentarily.

[Beth Dakin]

Re-committed with revision 101290.

[Beth Dakin]

The bots are not fully cooperating right now, but I they made it far enough through the build to catch a failure before going offline for a moment. Hopefully it's the only one. I committed a Chromium build fix with revision 101296.

[Beth Dakin]

Aaand, revision 101306 is another Chromium build fix.