Bug 222216 – [iOS] Add a watchdog timer to forcibly reset deferring gesture recognizers

• Status: RESOLVED
• Resolution: FIXED
• Component: UI Events

[Wenson Hsieh]

...with a log fault or something.

This should make it significantly easier to diagnose the family of bugs that result from WKDeferringGestureRecognizers being permanently stuck in Possible state.

[Wenson Hsieh]

Created attachment 421239 [details]
Patch

[Wenson Hsieh]

Created attachment 421240 [details]
Patch

[Wenson Hsieh]

Created attachment 421241 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 421241 [details]
Patch

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

> Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:502
> +@interface WKContentView (WKInteraction) <UIGestureRecognizerDelegate, UITextAutoscrolling, UITextInputMultiDocument, UITextInputPrivate, UIWebFormAccessoryDelegate, UIWebTouchEventsGestureRecognizerDelegate, UIWKInteractionViewProtocol, WKActionSheetAssistantDelegate, WKFileUploadPanelDelegate, WKKeyboardScrollViewAnimatorDelegate , WKDeferringGestureRecognizerDelegate

extra space here.

[Wenson Hsieh]

Comment on attachment 421241 [details]
Patch

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

Thanks for the review!

> Source/WebKit/UIProcess/ios/GestureRecognizerConsistencyEnforcer.mm:34
> +GestureRecognizerConsistencyEnforcer::GestureRecognizerConsistencyEnforcer(WKContentView *view)

I also forgot to wrap this in a `PLATFORM(IOS_FAMILY)` guard, so this is currently failing macOS builds.

>> Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:502
>> +@interface WKContentView (WKInteraction) <UIGestureRecognizerDelegate, UITextAutoscrolling, UITextInputMultiDocument, UITextInputPrivate, UIWebFormAccessoryDelegate, UIWebTouchEventsGestureRecognizerDelegate, UIWKInteractionViewProtocol, WKActionSheetAssistantDelegate, WKFileUploadPanelDelegate, WKKeyboardScrollViewAnimatorDelegate , WKDeferringGestureRecognizerDelegate
> 
> extra space here.

Good catch — fixed!

[Wenson Hsieh]

> /Volumes/Data/worker/watchOS-7-Simulator-Build-EWS/build/WebKitBuild/Release-watchsimulator/WebCore.framework/PrivateHeaders/UIEvent.h:35:7: note: candidate found by name lookup is 'WebCore::UIEvent'
> class UIEvent : public Event {
>       ^
> In file included from /Volumes/Data/worker/watchOS-7-Simulator-Build-EWS/build/WebKitBuild/Release-watchsimulator/DerivedSources/WebKit2/unified-sources/UnifiedSource48-mm.mm:7:
> /Volumes/Data/worker/watchOS-7-Simulator-Build-EWS/build/Source/WebKit/UIProcess/ios/forms/WKFocusedFormControlView.mm:136:34: error: cannot initialize a parameter of type 'UIEvent *' with an lvalue of type 'WebCore::UIEvent *'
>     [self _wheelChangedWithEvent:event];

watchOS build failure is due to unified sources grouping `WebPageProxyIOS.mm` in with `WKFocusedFormControlView.mm`, and then WebKit code doesn't know how to disambiguate `UIEvent` from UIKit vs. `WebCore::UIEvent`.

The declaration for `WebCore::UIEvent` is coming from this include chain:

> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/WebKitBuild/Release-watchos/DerivedSources/WebKit2/unified-sources/UnifiedSource48-mm.mm:1:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:27:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/Source/WebKit/UIProcess/WebPageProxy.h:70:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/Source/WebKit/UIProcess/WebFrameProxy.h:30:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/Source/WebKit/UIProcess/GenericCallback.h:33:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/Source/WebKit/UIProcess/API/C/WKAPICast.h:44:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/Source/WebKit/Shared/API/c/WKSharedAPICast.h:50:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/Source/WebKit/Shared/WebMouseEvent.h:34:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/WebKitBuild/Release-watchos/WebCore.framework/PrivateHeaders/PointerEvent.h:29:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/WebKitBuild/Release-watchos/WebCore.framework/PrivateHeaders/MouseEvent.h:27:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/WebKitBuild/Release-watchos/WebCore.framework/PrivateHeaders/MouseEventInit.h:28:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/WebKitBuild/Release-watchos/WebCore.framework/PrivateHeaders/MouseRelatedEvent.h:27:
> In file included from /Volumes/Data/worker/watchOS-7-Build-EWS/build/WebKitBuild/Release-watchos/WebCore.framework/PrivateHeaders/UIEventWithKeyState.h:28:

...it seems less than ideal for a shared UIProcess/WebProcess header (`WebMouseEvent.h`) to be importing WebCore headers that know about the DOM (`PointerEvent.h`).

[Wenson Hsieh]

Created attachment 421281 [details]
For EWS (fix builds + rebase)

[Wenson Hsieh]

Created attachment 421287 [details]
Unified source build fix

[EWS]

Committed r273305: <https://commits.webkit.org/r273305>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 421287 [details].

[Radar WebKit Bug Importer]

<rdar://problem/74639714>