[Webkit-unassigned] [Bug 179397] [iOS] Use new class name from UIKit when checking UITextSuggestion type for WebKitLegacy

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 8 15:55:44 PST 2017


https://bugs.webkit.org/show_bug.cgi?id=179397

Wenson Hsieh <wenson_hsieh at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wenson_hsieh at apple.com

--- Comment #2 from Wenson Hsieh <wenson_hsieh at apple.com> ---
Comment on attachment 326268
  --> https://bugs.webkit.org/attachment.cgi?id=326268
Patch

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

Good catch, Frederik! Just a few comments, inline.

> Source/WebKitLegacy/mac/DOM/DOMHTMLInputElement.mm:39
> +// FIXME: This can be safely removed once <rdar://problem/34583628> lands in the SDK.

This @implementation can be safely removed now :)

Instead of making pieces of DOMHTMLInputElement.mm contingent on USE(APPLE_INTERNAL_SDK), I think we should instead define the new interfaces as needed to build against an SDK without this header. In other words, we should be doing something along the lines of:

#if TARGET_OS_IPHONE
#if __has_include(<UIKit/UITextAutofillSuggestion.h>)

// Just import the header directly.

#else

// Declare an @interface for UITextAutofillSuggestion, with whichever properties we'll need to build.

#endif
#endif // TARGET_OS_IPHONE

> Source/WebKitLegacy/mac/DOM/DOMHTMLInputElement.mm:706
>  #if USE(APPLE_INTERNAL_SDK) && TARGET_OS_IPHONE

I know this isn't new with this patch, but we should really make this guarded on just TARGET_OS_PHONE, and not additionally guard it with USE(APPLE_INTERNAL_SDK). In general, we strive to only have USE(APPLE_INTERNAL_SDK) in headers rather than implementation files. That way, WebKit built with the internal SDK won't behave differently than WebKit built using OpenSource (there are some exceptions, as you probably recall, but this case in particular isn't one where we need to draw a distinction between internal/open source configurations).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171108/978c6d7d/attachment.html>


More information about the webkit-unassigned mailing list