Created attachment 410637 [details] test list for reproduction Description: http/tests/in-app-browser-privacy/non-app-bound-domain-does-not-get-app-bound-session.html The first failure after a series of constant passes that I see this on the dashboard was 09/29/20 at 267768, but does not appear to be relevant to what would have caused this. I can reproduce this on r267763, but unable to reproduce on r267762. Commit r267763 has to do with moving things on WebProcessPool associated with NetworkProcessProxy ownership and moves them to WebsiteDataStore, which could have introduced the constant failure. The change was introduced here https://trac.webkit.org/changeset/267763/webkit. REPRODUCTION STEPS Command: run-webkit-tests --ios-simulator --no-retry --force -f --test-list testlist.txt Result: r268044 failure (ToT) r267765 failure r267763 failure r267762 pass r267761 pass Regressions: Unexpected text-only failures (3) http/tests/cookies/js-get-and-set-http-only-cookie.html [ Failure ] http/tests/download/inherited-encoding-form-submission-result.html [ Failure ] http/tests/in-app-browser-privacy/non-app-bound-domain-does-not-get-app-bound-session.html [ Failure ] History: https://results.webkit.org/?suite=layout-tests&test=http%2Ftests%2Fin-app-browser-privacy%2Fnon-app-bound-domain-does-not-get-app-bound-session.html&platform=ios&limit=50000 Diff Log: --- /Volumes/Data/Builds/build-267763/layout-test-results/http/tests/in-app-browser-privacy/non-app-bound-domain-does-not-get-app-bound-session-expected.txt +++ /Volumes/Data/Builds/build-267763/layout-test-results/http/tests/in-app-browser-privacy/non-app-bound-domain-does-not-get-app-bound-session-actual.txt @@ -3,8 +3,9 @@ On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". -PASS Origin has non-app-bound session. +FAIL Origin started with app-bound session. PASS successfullyParsed is true +Some tests failed. TEST COMPLETE
<rdar://problem/69999900>
ASSERTION FAILED: applicationBundleIsEqualTo() and applicationBundleStartsWith() should not be called before setApplicationBundleIdentifier() !applicationBundleIdentifierOverrideWasQueried ./platform/cocoa/RuntimeApplicationChecksCocoa.mm(80) : void WebCore::setApplicationBundleIdentifierOverride(const WTF::String &) 1 0x10ba1f409 WTFCrash 2 0x1272e6113 WebCore::setApplicationBundleIdentifierOverride(WTF::String const&) 3 0x115cc7421 +[WKWebView(WKTesting) _setApplicationBundleIdentifier:] 4 0x10a9968c4 WTR::TestController::setApplicationBundleIdentifier(WTF::String const&) 5 0x10a956346 WTR::TestController::createWebViewWithOptions(WTR::TestOptions const&) 6 0x10a957da0 WTR::TestController::ensureViewSupportsOptionsForTest(WTR::TestInvocation const&) 7 0x10a95c0b4 WTR::TestController::configureViewForTest(WTR::TestInvocation const&) 8 0x10a99b4c5 WTR::TestInvocation::invoke() 9 0x10a95c6a2 WTR::TestController::runTest(char const*) 10 0x10a95d0f6 WTR::TestController::runTestingServerLoop() 11 0x10a9530b7 WTR::TestController::run() 12 0x10a9529b7 WTR::TestController::TestController(int, char const**) 13 0x10a953183 WTR::TestController::TestController(int, char const**) 14 0x10a938c4c -[WebKitTestRunnerApp _runTestController] 15 0x7fff208703df __NSThreadPerformPerform 16 0x7fff203a9132 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 17 0x7fff203a902a __CFRunLoopDoSource0 18 0x7fff203a856e __CFRunLoopDoSources0 19 0x7fff203a2cd7 __CFRunLoopRun 20 0x7fff203a247e CFRunLoopRunSpecific 21 0x7fff2ba9ddb3 GSEventRunModal 22 0x7fff24682607 -[UIApplication _run] 23 0x7fff246874b8 UIApplicationMain 24 0x10a938de7 main 25 0x7fff20258405 start 26 0x2
*** Bug 217406 has been marked as a duplicate of this bug. ***
Created attachment 410706 [details] Patch
Comment on attachment 410706 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=410706&action=review > Tools/WebKitTestRunner/TestController.cpp:646 > + clearApplicationBundleIdentifierTestingOverride(); I think this should come before RELEASE_ASSERT(!m_hasSetApplicationBundleIdentifier). Otherwise it doesn't make sense. m_hasSetApplicationBundleIdentifier is set to false when the bundle ID is cleared.
Created attachment 410712 [details] Patch
(In reply to Alex Christensen from comment #6) > Created attachment 410712 [details] > Patch I think this looks good as long as EWS is happy.
This didn't fix it in my release build. Needs more investigation, but it is just a test infrastructure issue with the override bundle identifier, which is only used for tests. We are now creating the network process before setting the override bundle identifier, which causes the assertion and test failures. The solution is to set the test override bundle id earlier.
Created attachment 410755 [details] Patch
Comment on attachment 410755 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=410755&action=review Thanks for fixing this, and making these tests more robust in the process. > Source/WebKit/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:-119 > - m_isInAppBrowserPrivacyTestModeEnabled = [defaults boolForKey:[NSString stringWithFormat:@"WebKitDebug%@", WebPreferencesKey::isInAppBrowserPrivacyEnabledKey().createCFString().get()]]; We should probably remove this entry from WebPreferencesDebug.yaml now that it is unused.
Created attachment 410791 [details] Patch
(In reply to katherine_cheney from comment #10) > Comment on attachment 410755 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=410755&action=review > > Thanks for fixing this, and making these tests more robust in the process. > > > Source/WebKit/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:-119 > > - m_isInAppBrowserPrivacyTestModeEnabled = [defaults boolForKey:[NSString stringWithFormat:@"WebKitDebug%@", WebPreferencesKey::isInAppBrowserPrivacyEnabledKey().createCFString().get()]]; > > We should probably remove this entry from WebPreferencesDebug.yaml now that > it is unused. Wait! I'd like to use it for some debug logging we were thinking about.
Comment on attachment 410791 [details] Patch Actually, on second thought let's go ahead and remove all this. We can use a specific preference flag to trigger logging without needing to keep all of this cruft around. r=me
Committed r268214: <https://trac.webkit.org/changeset/268214> All reviewed patches have been landed. Closing bug and clearing flags on attachment 410791 [details].