Bug 127471 - [iOS] [WK2] WKContentView has a black background
Summary: [iOS] [WK2] WKContentView has a black background
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2014-01-23 01:15 PST by Tim Horton
Modified: 2014-01-23 10:47 PST (History)
3 users (show)

See Also:


Attachments
patch (2.17 KB, patch)
2014-01-23 01:19 PST, Tim Horton
sam: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2014-01-23 01:15:16 PST
... which is frequently exposed during loading.

It shouldn't be black (it shouldn't need a background at all!).

<rdar://problem/12287363>
Comment 1 Tim Horton 2014-01-23 01:19:25 PST
Created attachment 221961 [details]
patch
Comment 2 Ian Henderson 2014-01-23 02:20:06 PST
Comment on attachment 221961 [details]
patch

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

> Source/WebKit2/UIProcess/API/ios/WKContentView.mm:52
> +@end

Is this how we deal with private headers on the Mac?  Why even include the private header if we're going to make this category?
Comment 3 Sam Weinig 2014-01-23 07:44:16 PST
Comment on attachment 221961 [details]
patch

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

>> Source/WebKit2/UIProcess/API/ios/WKContentView.mm:52
>> +@end
> 
> Is this how we deal with private headers on the Mac?  Why even include the private header if we're going to make this category?

I think we usually do the category as an #else clause.
Comment 4 Sam Weinig 2014-01-23 07:45:11 PST
(In reply to comment #3)
> (From update of attachment 221961 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=221961&action=review
> 
> >> Source/WebKit2/UIProcess/API/ios/WKContentView.mm:52
> >> +@end
> > 
> > Is this how we deal with private headers on the Mac?  Why even include the private header if we're going to make this category?
> 
> I think we usually do the category as an #else clause.

Oh, and reason we do it is to catch errors for people who have the header.
Comment 5 Tim Horton 2014-01-23 08:58:28 PST
(In reply to comment #4)
> (In reply to comment #3)
> > (From update of attachment 221961 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=221961&action=review
> > 
> > >> Source/WebKit2/UIProcess/API/ios/WKContentView.mm:52
> > >> +@end
> > > 
> > > Is this how we deal with private headers on the Mac?  Why even include the private header if we're going to make this category?
> > 
> > I think we usually do the category as an #else clause.
> 
> Oh, and reason we do it is to catch errors for people who have the header.

Exactly.

If we put it in an #else, we wouldn't (as readily) catch signature changes. I think the only case we use a #else is if we need to magic the class itself into existence (when the class itself is also private).
Comment 6 Anders Carlsson 2014-01-23 10:10:26 PST
Comment on attachment 221961 [details]
patch

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

> Source/WebKit2/UIProcess/API/ios/WKContentView.mm:46
> +#if defined(__has_include) && __has_include(<QuartzCore/QuartzCorePrivate.h>)

Do we really need the #if defined(__has_include) part here?
Comment 7 Tim Horton 2014-01-23 10:40:02 PST
(In reply to comment #6)
> (From update of attachment 221961 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=221961&action=review
> 
> > Source/WebKit2/UIProcess/API/ios/WKContentView.mm:46
> > +#if defined(__has_include) && __has_include(<QuartzCore/QuartzCorePrivate.h>)
> 
> Do we really need the #if defined(__has_include) part here?

I don’t think we do anymore (or maybe ever?)
Comment 8 Tim Horton 2014-01-23 10:47:49 PST
http://trac.webkit.org/changeset/162626