Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0d413afc34892b073ae15d899834307910820aa8
https://github.com/WebKit/WebKit/commit/0d413afc34892b073ae15d899834307910820aa8
Author: Chris Dumez <[email protected]>
Date: 2026-05-11 (Mon, 11 May 2026)
Changed paths:
M Tools/TestWebKitAPI/Tests/WebKit/WKPage/cocoa/EnableAccessibility.mm
Log Message:
-----------
WebKit.AccessibilityChildrenPreventsProcessSuspensionOnFrontmostTab API test
is flaky
https://bugs.webkit.org/show_bug.cgi?id=314544
rdar://176588587
Reviewed by Ben Nham.
The remote AX element token is sent asynchronously from the WebProcess via the
RegisterWebProcessAccessibilityToken IPC. The test calls -accessibilityChildren
immediately after -synchronouslyLoadTestPageNamed:, which only waits for the
navigation to finish, not for the AX token IPC to arrive.
When the token has not arrived yet, WebViewImpl::accessibilityAttributeValue's
NSAccessibilityChildrenAttribute branch sees a null m_remoteAccessibilityChild,
returns nil, and skips the call to takeAccessibilityActivityWhenInWindow().
This causes all three EXPECTs in the test to fail in sequence:
1. [children count] is 0 because the children array is nil.
2. _hasAccessibilityActivityForTesting is false because
takeAccessibilityActivity()
was never called.
3. After re-adding the view to the window, _hasAccessibilityActivityForTesting
is still false because m_takeAccessibilityActivityWhenInWindow was never set,
so WebProcessActivityState::viewDidEnterWindow() does nothing.
Wrap the first -accessibilityChildren read in a Util::waitFor that polls until
the token has been received. Once that first call succeeds, the rest of the
test is deterministic.
* Tools/TestWebKitAPI/Tests/WebKit/WKPage/cocoa/EnableAccessibility.mm:
(TEST(WebKit, AccessibilityChildrenPreventsProcessSuspensionOnFrontmostTab)):
Canonical link: https://commits.webkit.org/313040@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
