Bug 206759 – REGRESSION: [ iPadOS ] imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html always fails

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jacob Uphoff]

imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html is flaky failing on iOS starting around commit 254340
I did not try to reproduce 

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

Diff:
--- /Volumes/Data/slave/ipados-simulator-13-debug-tests-wk2/build/layout-test-results/imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements-expected.txt
+++ /Volumes/Data/slave/ipados-simulator-13-debug-tests-wk2/build/layout-test-results/imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements-actual.txt
@@ -1,3 +1,4 @@
+ 
 
 PASS Can dispatch untrusted 'click' Events at disabled HTML elements. 
 PASS Can dispatch untrusted Events at disabled HTML elements. 
@@ -7,5 +8,5 @@
 PASS CSS Transitions transitioncancel event fires on disabled form elements 
 PASS CSS Animation animationstart, animationiteration, animationend fire on disabled form elements 
 PASS CSS Animation's animationcancel event fires on disabled form elements 
-PASS Real clicks on disabled elements must not dispatch events. 
+FAIL Real clicks on disabled elements must not dispatch events. assert_true: HTMLTextAreaElement is enabled, so onclick must fire. expected true got false

[Radar WebKit Bug Importer]

<rdar://problem/58872607>

[David Kilzer (:ddkilzer)]

This is the same issue as Bug 205458, but that fix in r254082 only addressed test failures in iPhone Simulator, not iPad Simulator.

This test continues to fail on iPad Simulator but pass on iPhone Simulator:

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

[David Kilzer (:ddkilzer)]

Created attachment 389092 [details]
Patch v1

[David Kilzer (:ddkilzer)]

(In reply to David Kilzer (:ddkilzer) from comment #3)
> Created attachment 389092 [details]
> Patch v1

This patch may end up fixing a few tests for iPadOS.  Need to let bots chew on it.

Just running 60/66 tests in LayoutTests/imported/w3c/web-platform-tests/dom/events:

$ ./Tools/Scripts/run-webkit-tests --release --no-build --ipad-sim --iterations 1 --no-retry-failures --no-show-results --child-processes=1 LayoutTests/imported/w3c/web-platform-tests/dom/events/

Found these tests now passing (failure text is now passing text):

[47/66] imported/w3c/web-platform-tests/dom/events/EventTarget-dispatchEvent.html failed unexpectedly (text diff)
[50/66] imported/w3c/web-platform-tests/dom/events/document-level-touchmove-event-listener-passive-by-default.html failed unexpectedly (text diff)

[David Kilzer (:ddkilzer)]

Created attachment 389095 [details]
Patch v2

[David Kilzer (:ddkilzer)]

(In reply to David Kilzer (:ddkilzer) from comment #5)
> Created attachment 389095 [details]
> Patch v2

Guessing which "UIKitSPI.h" to update is maddening.  There should be only one.

[David Kilzer (:ddkilzer)]

Comment on attachment 389095 [details]
Patch v2

Ready for review.

[David Kilzer (:ddkilzer)]

(In reply to David Kilzer (:ddkilzer) from comment #7)
> Comment on attachment 389095 [details]
> Patch v2
> 
> Ready for review.

The patch doesn't introduce any new test failures that I'm aware of, and fixes imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html on iPadOS.

[Alexey Proskuryakov]

Do we know why this regressed?

[David Kilzer (:ddkilzer)]

(In reply to Alexey Proskuryakov from comment #9)
> Do we know why this regressed?

According to the flakiness dashboard:

<https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fdom%2Fevents%2FEvent-dispatch-on-disabled-elements.html&model=iPad%20(5th%20generation)>

This regressed between r252460-r252464:

<https://trac.webkit.org/log/webkit/trunk?action=follow_copy&mode=follow_copy&rev=252464&stop_rev=252460&limit=100>

The only commit in that range that may be related is r252461:

[Web Animations] Accelerated transitions do not always remove their backing accelerated animation
<​https://bugs.webkit.org/show_bug.cgi?id=204198>
<https://trac.webkit.org/changeset/252461/webkit>

I am not familiar enough with Web Animations to be able to suggest why this may have caused this regression, though.

[David Kilzer (:ddkilzer)]

Created attachment 389362 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 389362 [details]
Patch for landing

Rejecting attachment 389362 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-03', 'validate-changelog', '--check-oops', '--non-interactive', 389362, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

ChangeLog entry in Source/WebKit/ChangeLog contains OOPS!.

Full output: https://webkit-queues.webkit.org/results/13314632

[David Kilzer (:ddkilzer)]

(In reply to David Kilzer (:ddkilzer) from comment #11)
> Created attachment 389362 [details]
> Patch for landing

This patch is identical to "Patch v1" (attachment 389095 [details]) except for the updated title in the ChangeLog.

[WebKit Commit Bot]

Comment on attachment 389362 [details]
Patch for landing

Clearing flags on attachment: 389362

Committed r255507: <https://trac.webkit.org/changeset/255507>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.