Bug 184742 – AX: [macOS] WebKit hangs when triggering an alert from an AOM increment event

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Nan Wang]

WebKit hangs when triggering an alert from an AOM increment event

<rdar://problem/39477716>

[Nan Wang]

Created attachment 338238 [details]
patch

[chris fleizach]

Comment on attachment 338238 [details]
patch

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

> Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:3593
> +    else if ([action isEqualToString:@"AXSyncDecrementAction"])

Should we remove the sync versions and fix the other tests? The sync versions aren’t that real anymore. What do you think

[Nan Wang]

(In reply to chris fleizach from comment #2)
> Comment on attachment 338238 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=338238&action=review
> 
> > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:3593
> > +    else if ([action isEqualToString:@"AXSyncDecrementAction"])
> 
> Should we remove the sync versions and fix the other tests? The sync
> versions aren’t that real anymore. What do you think

I tried to do that but a lot of the tests are doing increment/decrement multiple times and then check the value. That would require us to put tons of setTimeout in the tests and make them less readable.

Another concern is that this is only Mac but some tests are for all platforms so it's not reasonable to make them wait.

I think the core is not changed just the timing might be affected on macOS, so maybe keeping the sync version is not a bad idea?

[WebKit Commit Bot]

Comment on attachment 338238 [details]
patch

Clearing flags on attachment: 338238

Committed r230782: <https://trac.webkit.org/changeset/230782>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Ryan Haddad]

The test for this change is frequently failing on macOS Debug bots:
https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=accessibility%2Fmac%2Fasync-increment-decrement-action.html

--- /Volumes/Data/slave/highsierra-debug-tests-wk2/build/layout-test-results/accessibility/mac/async-increment-decrement-action-expected.txt
+++ /Volumes/Data/slave/highsierra-debug-tests-wk2/build/layout-test-results/accessibility/mac/async-increment-decrement-action-actual.txt
@@ -6,8 +6,8 @@
 
 PASS obj.intValue is 25
 PASS obj.intValue is 25
-PASS obj.intValue is 50
-PASS obj.intValue is 50
+FAIL obj.intValue should be 50. Was 25.
+FAIL obj.intValue should be 50. Was 25.
 PASS obj.intValue is 25
 PASS successfullyParsed is true

[Nan Wang]

(In reply to Ryan Haddad from comment #6)
> The test for this change is frequently failing on macOS Debug bots:
> https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.
> html#showAllRuns=true&tests=accessibility%2Fmac%2Fasync-increment-decrement-
> action.html
> 
> ---
> /Volumes/Data/slave/highsierra-debug-tests-wk2/build/layout-test-results/
> accessibility/mac/async-increment-decrement-action-expected.txt
> +++
> /Volumes/Data/slave/highsierra-debug-tests-wk2/build/layout-test-results/
> accessibility/mac/async-increment-decrement-action-actual.txt
> @@ -6,8 +6,8 @@
>  
>  PASS obj.intValue is 25
>  PASS obj.intValue is 25
> -PASS obj.intValue is 50
> -PASS obj.intValue is 50
> +FAIL obj.intValue should be 50. Was 25.
> +FAIL obj.intValue should be 50. Was 25.
>  PASS obj.intValue is 25
>  PASS successfullyParsed is true

Ok looking

[Nan Wang]

will be fixing the flaky test in
https://bugs.webkit.org/show_bug.cgi?id=184834