Bug 127471

Summary: [iOS] [WK2] WKContentView has a black background
Product: WebKit Reporter: Tim Horton <thorton>
Component: WebKit2Assignee: Tim Horton <thorton>
Status: RESOLVED FIXED    
Severity: Normal CC: andersca, sam, simon.fraser
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch sam: review+

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