Title: [282719] trunk/Tools
- Revision
- 282719
- Author
- [email protected]
- Date
- 2021-09-17 20:27:53 -0700 (Fri, 17 Sep 2021)
Log Message
[ macOS Release ] TestWebKitAPI.NetworkProcess.BroadcastChannelCrashRecovery is flaky timing out
https://bugs.webkit.org/show_bug.cgi?id=230430
<rdar://problem/83256307>
Reviewed by Alex Christensen.
I suspect that the flakiness is due to the BroadcastChannel.postMessage() sometimes failing right
after we kill the network process and relaunch it. I believe this could happen because the test
was only making sure that `[[WKWebsiteDataStore defaultDataStore] _networkProcessIdentifier]`
changed. This meant that the UIProcess was indeed notified that the network process crashed and
that a new one was relaunched. However, this doesn't necessarily indicate that the view's
WebProcesses were notified yet. As a result, when we evaluate JS to post a message on a
BroadcastChannel, the WebProcess could potentially still try to send the IPC via the
IPC::Connection for the old network process.
To try and address this race, I am adding code to wait until cookie synchronization is
working across both web views before I try posting the message. Because cookie synchronization
involves the network process and both WebProcesses, once this happens, we know that both
WebProcesses are properly connected to the new NetworkProcess.
* TestWebKitAPI/Tests/WebKitCocoa/NetworkProcess.mm:
(waitUntilNetworkProcessIsResponsive):
(TEST):
Modified Paths
Diff
Modified: trunk/Tools/ChangeLog (282718 => 282719)
--- trunk/Tools/ChangeLog 2021-09-18 02:30:42 UTC (rev 282718)
+++ trunk/Tools/ChangeLog 2021-09-18 03:27:53 UTC (rev 282719)
@@ -1,3 +1,29 @@
+2021-09-17 Chris Dumez <[email protected]>
+
+ [ macOS Release ] TestWebKitAPI.NetworkProcess.BroadcastChannelCrashRecovery is flaky timing out
+ https://bugs.webkit.org/show_bug.cgi?id=230430
+ <rdar://problem/83256307>
+
+ Reviewed by Alex Christensen.
+
+ I suspect that the flakiness is due to the BroadcastChannel.postMessage() sometimes failing right
+ after we kill the network process and relaunch it. I believe this could happen because the test
+ was only making sure that `[[WKWebsiteDataStore defaultDataStore] _networkProcessIdentifier]`
+ changed. This meant that the UIProcess was indeed notified that the network process crashed and
+ that a new one was relaunched. However, this doesn't necessarily indicate that the view's
+ WebProcesses were notified yet. As a result, when we evaluate JS to post a message on a
+ BroadcastChannel, the WebProcess could potentially still try to send the IPC via the
+ IPC::Connection for the old network process.
+
+ To try and address this race, I am adding code to wait until cookie synchronization is
+ working across both web views before I try posting the message. Because cookie synchronization
+ involves the network process and both WebProcesses, once this happens, we know that both
+ WebProcesses are properly connected to the new NetworkProcess.
+
+ * TestWebKitAPI/Tests/WebKitCocoa/NetworkProcess.mm:
+ (waitUntilNetworkProcessIsResponsive):
+ (TEST):
+
2021-09-17 Kevin Neal <[email protected]>
[results.webkit.org] Add ability to access Bugzilla and Radar links from commit messages
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/NetworkProcess.mm (282718 => 282719)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/NetworkProcess.mm 2021-09-18 02:30:42 UTC (rev 282718)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/NetworkProcess.mm 2021-09-18 03:27:53 UTC (rev 282719)
@@ -36,6 +36,7 @@
#import <WebKit/_WKWebsiteDataStoreConfiguration.h>
#import <wtf/BlockPtr.h>
#import <wtf/RetainPtr.h>
+#import <wtf/UUID.h>
#import <wtf/Vector.h>
TEST(NetworkProcess, Entitlements)
@@ -210,6 +211,27 @@
}
@end
+static void waitUntilNetworkProcessIsResponsive(WKWebView *webView1, WKWebView *webView2)
+{
+ // We've just terminated and relaunched the network process. However, there is no easy well to tell if the webviews'
+ // WebProcesses have been notified of the network process crash or not (we only know that the UIProcess was). Because
+ // we don't want the test to go on with the WebProcesses using stale NetworkProcessConnections, we use the following
+ // trick to wait until both WebProcesses are able to communicate with the new NetworkProcess:
+ // The first WebProcess tries setting a cookie until the second Webview is able to see it.
+ auto expectedCookieString = makeString("TEST=", createCanonicalUUIDString());
+ auto setTestCookieString = makeString("setInterval(() => { document.cookie='", expectedCookieString, "'; }, 100);");
+ [webView1 evaluateJavaScript:(NSString *)setTestCookieString completionHandler: [&] (id result, NSError *error) {
+ EXPECT_TRUE(!error);
+ }];
+
+ bool canSecondWebViewSeeNewCookie = false;
+ do {
+ TestWebKitAPI::Util::spinRunLoop(10);
+ String cookieString = (NSString *)[webView2 objectByEvaluatingJavaScript:@"document.cookie"];
+ canSecondWebViewSeeNewCookie = cookieString.contains(expectedCookieString);
+ } while (!canSecondWebViewSeeNewCookie);
+}
+
TEST(NetworkProcess, BroadcastChannelCrashRecovery)
{
auto webViewConfiguration = adoptNS([[WKWebViewConfiguration alloc] init]);
@@ -279,6 +301,8 @@
while ([[WKWebsiteDataStore defaultDataStore] _networkProcessIdentifier] == networkPID)
TestWebKitAPI::Util::spinRunLoop(10);
+ waitUntilNetworkProcessIsResponsive(webView1.get(), webView2.get());
+
// Test that initial communication from webView1 to webView2 works.
receivedMessage = false;
receivedMessages.clear();
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
