Summary: | Support transparent WKWebViews | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Anders Carlsson <andersca> | ||||
Component: | New Bugs | Assignee: | Anders Carlsson <andersca> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | benjamin | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Anders Carlsson
2014-07-09 14:47:02 PDT
Created attachment 234659 [details]
Patch
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? Committed r170935: <http://trac.webkit.org/changeset/170935> The background color is quite broken on load in Safari. This looks related. 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. |