Summary: | REGRESSION: [ iOS ] imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html is failing | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Truitt Savell <tsavell> | ||||
Component: | DOM | Assignee: | Antoine Quint <graouts> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | commit-queue, dbates, ddkilzer, graouts, thorton, webkit-bot-watchers-bugzilla, webkit-bug-importer, wenson_hsieh | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=206759 | ||||||
Attachments: |
|
Description
Truitt Savell
2019-12-19 09:34:23 PST
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. 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. 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. 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. 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. (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. 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]; Created attachment 386841 [details]
Patch
Comment on attachment 386841 [details] Patch Clearing flags on attachment: 386841 Committed r254082: <https://trac.webkit.org/changeset/254082> All reviewed patches have been landed. Closing bug. 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> |