Bug 69040 – ScrollbarThemeComposite requires a ScrollView to draw scroll corner

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

Not every ScrollableArea is a ScrollView, much less a FrameView.

Talking to Page from platform code is obviously a layering violation, but I'm going to take the easy way out and just skip over failing code when there is no ScrollView.

[Alexey Proskuryakov]

Created attachment 109095 [details]
proposed fix

[Simon Fraser (smfr)]

Comment on attachment 109095 [details]
proposed fix

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

> Source/WebCore/platform/qt/ScrollbarThemeQt.cpp:248
> +    // FIXME: It's incorrect to do invalidation while painting.
>      if (context->updatingControlTints()) {
>         scrollView->invalidateRect(rect);

It's actually OK during the "updatingControlTints" paint phase. This is a special paint whose sole purpose is to invalidate things whose appearance changes based on the window's activation state.

[Alexey Proskuryakov]

I need to make sure that Qt doesn't crash with null scrollView here.

Normally, it's something a caller does (e.g. in FrameView).

[Alexey Proskuryakov]

Created attachment 109177 [details]
patch with Qt fix

[Alexey Proskuryakov]

Comment on attachment 109177 [details]
patch with Qt fix

If this breaks something in Qt, platform/qt/ScrollbarThemeQt.cpp change alone can be reverted for now. But I'll need a good deal of detail about failures to fix (what calls ScrollbarThemeQt::paintScrollCorner() bypassing cross-platform code?)

[WebKit Review Bot]

Comment on attachment 109177 [details]
patch with Qt fix

Clearing flags on attachment: 109177

Committed r96348: <http://trac.webkit.org/changeset/96348>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.