TestWebKitAPI.WebSocket.PageWithAttributedBundleIdentifierDestroyed is a constant timeout on macOS Monterey. HISTORY: https://results.webkit.org/?suite=api-tests&test=TestWebKitAPI.WebSocket.PageWithAttributedBundleIdentifierDestroyed
<rdar://problem/85482210>
I was able to reproduce this timeout on a Release ToT build. Using the following test: Run-api-tests --release TestWebKitAPI.WebSocket.PageWithAttributedBundleIdentifierDestroyed I do want to note that I was not able to reproduce this with a Debug or a Production build. I had to specifically download a Release build, and that's where I was easily able to reproduce the timeout.
It seems that setting _attributedBundleIdentifier to a bundle id that doesn't exist causes it to be unable to make a network request.
Created attachment 447611 [details] Patch
Comment on attachment 447611 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=447611&action=review > Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm:1767 > + if (!parameters.attributedBundleIdentifier().startsWith("com.apple.webkit.test.bundle.identifier")) Building the name of the test bundle right into the binary is usually something we try very hard to avoid. Isn’t there some other way the test could inject the evidence that it’s a test configuration?
Comment on attachment 447611 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=447611&action=review >> Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm:1767 >> + if (!parameters.attributedBundleIdentifier().startsWith("com.apple.webkit.test.bundle.identifier")) > > Building the name of the test bundle right into the binary is usually something we try very hard to avoid. Isn’t there some other way the test could inject the evidence that it’s a test configuration? Like a separate boolean in the parameters.
Created attachment 447622 [details] Patch
https://trac.webkit.org/changeset/287275/webkit
r287359 enabled another test fixed by this.