Bug 134779 – Support transparent WKWebViews

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

[Anders Carlsson]

Support transparent WKWebViews

[Anders Carlsson]

Created attachment 234659 [details]
Patch

[Tim Horton]

Comment on attachment 234659 [details]
Patch

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

> Source/WebCore/ChangeLog:9
> +        Schedule rebuilding the compositing layers if a FrameView's transparency changes.

this definitely needs a "why" (though I vaguely remember from you showing me)

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:1173
> +    BOOL oldOpaque = self.opaque;

s/old/was/g?

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:1176
> +    [super setOpaque:opaque];
> +    [_contentView setOpaque:opaque];

why are these before the early return?

[Anders Carlsson]

Committed r170935: <http://trac.webkit.org/changeset/170935>

[Benjamin Poulain]

The background color is quite broken on load in Safari. This looks related.

[Benjamin Poulain]

Comment on attachment 234659 [details]
Patch

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

I think we should revert, we should not create our own behaviors different from regular UIScrollView.

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:665
> +    if (!webView.opaque)
> +        return WebCore::Color::transparent;

What?

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:672
> -        color = _page->pageExtendedBackgroundColor();
> +        color = webView->_page->pageExtendedBackgroundColor();

This is an invalid color until the first layer tree update!

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:1171
> +- (void)setOpaque:(BOOL)opaque

Opaque is a rendering hint, it does not work like that.