Bug 251306

Summary: [ iOS ] http/tests/in-app-browser-privacy/sub-frame-redirect-to-non-app-bound-domain-blocked.html is a flaky crash.
Product: WebKit Reporter: Bri Harris <bharris9>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: achristensen, ap, beidson, bfulgham, katherine_cheney, webkit-bot-watchers-bugzilla, webkit-bug-importer, wilander
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Crash Log none

Bri Harris
Reported 2023-01-27 19:19:28 PST
http/tests/in-app-browser-privacy/sub-frame-redirect-to-non-app-bound-domain-blocked.html is a flaky crash across iOS platforms. HISTORY: https://results.webkit.org/?suite=layout-tests&test=http%2Ftests%2Fin-app-browser-privacy%2Fsub-frame-redirect-to-non-app-bound-domain-blocked.html I attempted to replicate the failure as follows: run-webkit-test --iOS-simulator http/tests/in-app-browser-privacy/sub-frame-redirect-to-non-app-bound-domain-blocked.html I attempted running this test in iterations as well as in a test list with the issue not reproducing. Crash Log is attached.
Attachments
Crash Log (19.95 KB, text/plain)
2023-01-27 19:19 PST, Bri Harris 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Bri Harris
Comment 1 2023-01-27 19:19:56 PST
Created attachment 464696 [details] Crash Log
Bri Harris
Comment 2 2023-01-27 21:57:40 PST
Upon looking at the history, it looks like the first crash occurred at 255215@main. I was able to reproduce this crash at this build and later.
Radar WebKit Bug Importer
Comment 3 2023-01-27 21:59:15 PST
<rdar://problem/104774189>
Bri Harris
Comment 4 2023-01-27 22:01:15 PST
I was able to reproduce the crash at 255215@main as follows: run-webkit-test --iOS-simulator http/tests/in-app-browser-privacy/sub-frame-redirect-to-non-app-bound-domain-blocked.html
Bri Harris
Comment 5 2023-01-27 22:07:40 PST
Pull request: https://github.com/WebKit/WebKit/pull/9276
Alexey Proskuryakov
Comment 6 2023-01-28 16:23:10 PST
There is only one ASSERT in this function: // The bundle identifier can only be set once per test, and is cleared between tests. RELEASE_ASSERT(!m_hasSetApplicationBundleIdentifier); Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.webkit.WebKitTestRunnerApp 0x109cd6f62 WTFCrashWithInfo(int, char const*, char const*, int) 1 org.webkit.WebKitTestRunnerApp 0x109cec308 WTR::TestController::createWebViewWithOptions(WTR::TestOptions const&) 2 org.webkit.WebKitTestRunnerApp 0x109cec99e WTR::TestController::ensureViewSupportsOptionsForTest(WTR::TestInvocation const&) 3 org.webkit.WebKitTestRunnerApp 0x109cee7c8 WTR::TestController::configureViewForTest(WTR::TestInvocation const&) 4 org.webkit.WebKitTestRunnerApp 0x109d0952a WTR::TestInvocation::invoke() 5 org.webkit.WebKitTestRunnerApp 0x109cee95a WTR::TestController::runTest(char const*) The bundle identifier is set via a WKTR pragma, but why does this happen twice? I don't see any window.opens. <!DOCTYPE html><!-- webkit-test-runner [ enableInAppBrowserPrivacy=true applicationBundleIdentifier=inAppBrowserPrivacyTestIdentifier isAppBoundWebView=true ] -->
EWS
Comment 7 2023-01-30 12:05:40 PST
Test gardening commit 259579@main (bf9efb4e0c7e): <https://commits.webkit.org/259579@main> Reviewed commits have been landed. Closing PR #9276 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.