RESOLVED FIXED 213038
WebKit: Make UIGestureRecognizer build for watchOS and tvOS
https://bugs.webkit.org/show_bug.cgi?id=213038
Summary WebKit: Make UIGestureRecognizer build for watchOS and tvOS
Jonathan Bedard
Reported 2020-06-10 11:36:23 PDT
UIGestureRecognizer SPI is guarded by an iOS macro, but we need the definition for watchOS and tvOS.
Attachments
Patch (1.86 KB, patch)
2020-06-10 11:41 PDT, Jonathan Bedard
no flags
Patch (2.37 KB, patch)
2020-06-11 07:47 PDT, Jonathan Bedard
no flags
Patch (2.37 KB, patch)
2020-06-11 07:52 PDT, Jonathan Bedard
no flags
Patch (1.14 KB, patch)
2020-06-11 12:30 PDT, Jonathan Bedard
no flags
Patch for landing (1.14 KB, patch)
2020-06-11 13:21 PDT, Jonathan Bedard
no flags
Radar WebKit Bug Importer
Comment 1 2020-06-10 11:37:44 PDT
Jonathan Bedard
Comment 2 2020-06-10 11:41:16 PDT
Jonathan Bedard
Comment 3 2020-06-10 11:43:11 PDT
Comment on attachment 401561 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401561&action=review > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1457 > + return [recognizer respondsToSelector:@selector(modifierFlags)] ? [recognizer modifierFlags] : 0; This gets watchOS and tvOS building, but I'm pretty sure it's wrong.
Darin Adler
Comment 4 2020-06-10 11:59:00 PDT
Comment on attachment 401561 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401561&action=review >> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1457 >> + return [recognizer respondsToSelector:@selector(modifierFlags)] ? [recognizer modifierFlags] : 0; > > This gets watchOS and tvOS building, but I'm pretty sure it's wrong. Let's not commit something that we are pretty sure is wrong.
Tim Horton
Comment 5 2020-06-10 12:08:48 PDT
Comment on attachment 401561 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401561&action=review >>> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1457 >>> + return [recognizer respondsToSelector:@selector(modifierFlags)] ? [recognizer modifierFlags] : 0; >> >> This gets watchOS and tvOS building, but I'm pretty sure it's wrong. > > Let's not commit something that we are pretty sure is wrong. Jonathan, don't you just want to make UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS be true on watchOS and tvOS?
Tim Horton
Comment 6 2020-06-10 12:08:58 PDT
(In reply to Tim Horton from comment #5) > Comment on attachment 401561 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=401561&action=review > > >>> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1457 > >>> + return [recognizer respondsToSelector:@selector(modifierFlags)] ? [recognizer modifierFlags] : 0; > >> > >> This gets watchOS and tvOS building, but I'm pretty sure it's wrong. > > > > Let's not commit something that we are pretty sure is wrong. > > Jonathan, don't you just want to make UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS > be true on watchOS and tvOS? err, HAVE()
Jonathan Bedard
Comment 7 2020-06-10 12:15:24 PDT
Comment on attachment 401561 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401561&action=review >>>>> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1457 >>>>> + return [recognizer respondsToSelector:@selector(modifierFlags)] ? [recognizer modifierFlags] : 0; >>>> >>>> This gets watchOS and tvOS building, but I'm pretty sure it's wrong. >>> >>> Let's not commit something that we are pretty sure is wrong. >> >> Jonathan, don't you just want to make UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS be true on watchOS and tvOS? > > err, HAVE() Maybe? Shouldn't the definition of modifierFlags also be guarded by HAVE(UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS), in that case? I'm a bit confused by the original content of this line in the first place. It seems like it would only compile if the recognizer had a _modifierFlags member variable, which it doesn't seem to have for watchOS. I would expect this code to read: #if HAVE(UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS) return recognizer.modifierFlags; #else return 0; #endif
Tim Horton
Comment 8 2020-06-10 12:30:10 PDT
(In reply to Jonathan Bedard from comment #7) > Comment on attachment 401561 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=401561&action=review > > >>>>> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1457 > >>>>> + return [recognizer respondsToSelector:@selector(modifierFlags)] ? [recognizer modifierFlags] : 0; > >>>> > >>>> This gets watchOS and tvOS building, but I'm pretty sure it's wrong. > >>> > >>> Let's not commit something that we are pretty sure is wrong. > >> > >> Jonathan, don't you just want to make UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS be true on watchOS and tvOS? > > > > err, HAVE() > > Maybe? Shouldn't the definition of modifierFlags also be guarded by > HAVE(UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS), in that case? > > I'm a bit confused by the original content of this line in the first place. > It seems like it would only compile if the recognizer had a _modifierFlags > member variable, which it doesn't seem to have for watchOS. I would expect > this code to read: > > #if HAVE(UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS) > return recognizer.modifierFlags; > #else > return 0; > #endif 1) That's a method, not a member variable. 2) This is all because _modifierFlags used to exist on iOS as SPI and then became API (without the underscore) in iOS 13.4, it's got nothing to do with watchOS/etc., but your substitution is definitely wrong. 3) The header suggests that the watchOS 6 SDK has both the SPI and API versions available. So I think my suggestion is probably the right path forward, but you have alternative paths available if necessary.
Jonathan Bedard
Comment 9 2020-06-11 07:47:12 PDT
Jonathan Bedard
Comment 10 2020-06-11 07:52:36 PDT
Tim Horton
Comment 11 2020-06-11 10:47:40 PDT
Comment on attachment 401643 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401643&action=review > Source/WTF/wtf/PlatformHave.h:450 > +#if (PLATFORM(IOS_FAMILY) && __IPHONE_OS_VERSION_MIN_REQUIRED >= 130400) As previously mentioned, a IOS_FAMILY + IPHONE_OS_VERSION* check is always wrong. > Source/WebKit/Platform/spi/ios/UIKitSPI.h:422 > -#if PLATFORM(IOS) && !defined(__IPHONE_13_4) > +#if !HAVE(UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS) This used defined(__IPHONE_13_4) instead of MIN_REQUIRED for a reason! Blame it and see.
Tim Horton
Comment 12 2020-06-11 10:47:42 PDT
Comment on attachment 401643 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401643&action=review > Source/WTF/wtf/PlatformHave.h:450 > +#if (PLATFORM(IOS_FAMILY) && __IPHONE_OS_VERSION_MIN_REQUIRED >= 130400) As previously mentioned, a IOS_FAMILY + IPHONE_OS_VERSION* check is always wrong. > Source/WebKit/Platform/spi/ios/UIKitSPI.h:422 > -#if PLATFORM(IOS) && !defined(__IPHONE_13_4) > +#if !HAVE(UI_GESTURE_RECOGNIZER_MODIFIER_FLAGS) This used defined(__IPHONE_13_4) instead of MIN_REQUIRED for a reason! Blame it and see.
Jonathan Bedard
Comment 13 2020-06-11 12:30:50 PDT
Jonathan Bedard
Comment 14 2020-06-11 12:35:52 PDT
(In reply to Jonathan Bedard from comment #13) > Created attachment 401668 [details] > Patch I think I was trying way too hard. Seems that we don't need the SPI header at all. And actually, do we still need the SPI declaration for iOS once we move to 13.5, the old macros only work on 13.4, right?
Darin Adler
Comment 15 2020-06-11 12:51:12 PDT
Comment on attachment 401668 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401668&action=review > Source/WTF/wtf/PlatformHave.h:450 > +#if (PLATFORM(IOS) && __IPHONE_OS_VERSION_MIN_REQUIRED >= 130400 || PLATFORM(WATCHOS) || PLATFORM(APPLETV)) Seems like we could either remove the () entirely, or put them just around the && section.
Jonathan Bedard
Comment 16 2020-06-11 13:21:06 PDT
Created attachment 401677 [details] Patch for landing
EWS
Comment 17 2020-06-11 14:02:57 PDT
Committed r262924: <https://trac.webkit.org/changeset/262924> All reviewed patches have been landed. Closing bug and clearing flags on attachment 401677 [details].
Note You need to log in before you can comment on or make changes to this bug.