REGRESSION: [ iOS ] imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html is failing

[Truitt Savell]

imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html 

This test is failing constantly on iOS and has been very flakey. This was last modified in https://trac.webkit.org/changeset/253728/webkit
This is currently slowing down EWS

History:
https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fdom%2Fevents%2FEvent-dispatch-on-disabled-elements.html

[Radar WebKit Bug Importer]

<rdar://problem/58081704>

[Antoine Quint]

Right… so: it was failing constantly but I think this was addressed in r253746. This was based on results from EWS that somehow don't reproduce now, odd. I'll look into this shortly.

[Antoine Quint]

The failing test, "Real clicks on disabled elements must not dispatch events.", runs the same steps for five types of elements: "button", "fieldset", "input", "select" and "textarea", in that order.

If we run the steps for each element type individually, it passes. If we run "button", "fieldset", "input" and then either "select" or "textarea", it passes. However, if we try to run both of those, it fails.

Logging shows that we do not enter -[WKContentViewInteraction _singleTapRecognized:] after the "click" event to "select" has been delivered. My guess is that even though the "select" element has been removed, UIKit still delivers the immediate next tap to it and the WKContentView doesn't see it and fails to deliver the next tap to the Web content.

[Antoine Quint]

Adding this before continuing to the next element type fixes the issue:

    await new Promise(resolve => setTimeout(resolve, 1000));

We need to figure out why continuing the loop synchronously after the call to remove() fails.

[Daniel Bates]

Only considering what you wrote (I haven't looked at the test): my guess is that UIKit does **not** delivering the tap because the kit is animating a view and this is the default kit behavior. It's fixable.

[Antoine Quint]

So [_inputPeripheral beginEditing] is called in -[WKContentViewInteraction _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:] for the <select> element after we attempt to click on the <textarea> in the next loop iteration.

[Wenson Hsieh]

(In reply to Daniel Bates from comment #5)
> Only considering what you wrote (I haven't looked at the test): my guess is
> that UIKit does **not** delivering the tap because the kit is animating a
> view and this is the default kit behavior. It's fixable.

Dan's hunch is correct. WKScrollView is eating the subsequent touches after bringing up the input view, because it has active animations (i.e. the implementation of -[UIView hitTest:withEvent:]).

This happens because we're trying to zoom/scroll to reveal the focused element. To test this, I commented out the implementation of -[WKContentView _zoomToRevealFocusedElement], and saw that the flakiness did not reproduce.

[Wenson Hsieh]

A couple of potential ways to fix this:

1. Wait for animations on WKScrollView to finish before proceeding with a single tap in UIScriptControllerIOS::singleTapAtPointWithModifiers, like so:

+    NSDate *timeoutDate = [NSDate dateWithTimeIntervalSinceNow:someReasonableTimeoutDate];
+    while (webView().scrollView.layer.animationKeys.count) {
+        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:timeoutDate];
+        if ([timeoutDate compare:NSDate.date] == NSOrderedAscending)
+            break;
+    }

or,

2. Force animations to finish before proceeding with a single tap in UIScriptControllerIOS::singleTapAtPointWithModifiers, like so:

+    [webView().scrollView _removeAllAnimations:NO];

[Antoine Quint]

Created attachment 386841 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 386841 [details]
Patch

Clearing flags on attachment: 386841

Committed r254082: <https://trac.webkit.org/changeset/254082>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[David Kilzer (:ddkilzer)]

This fixed iPhone Simulator test failures, but not iPad Simulator test failures, which are tracked by:

Bug 206759: REGRESSION: [ iOS ] imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html is flaky failing
<https://bugs.webkit.org/show_bug.cgi?id=206759>