Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 7c33c64d1ef537430380dad36728614f7ce77e6c https://github.com/WebKit/WebKit/commit/7c33c64d1ef537430380dad36728614f7ce77e6c Author: Ben Nham <n...@apple.com> Date: 2024-03-01 (Fri, 01 Mar 2024)
Changed paths: M Source/WebKit/UIProcess/WebProcessPool.cpp M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm Log Message: ----------- Sever opener link for windows with an openee on manual navigation https://bugs.webkit.org/show_bug.cgi?id=270249 rdar://122506395 Reviewed by Chris Dumez. When a parent window uses window.open to create a child window, and the child window isn't closed, currently that causes all future navigations in the parent window to remain in the same process. In the case of a cross-origin manual navigation (e.g. navigation via the address bar), it should be safe to allow a process swap, as per the discussion here: https://github.com/whatwg/html/issues/5767#issuecomment-763855860 Note that Safari already almost always already has this behavior even though we don't do this at the engine level, since most location bar navigations occur in a new WKWebView. The new WKWebView has no opener link to the openee and loads in a different process. So there shouldn't be any new compatibility issues with doing this at the engine level as well. See also 272321@main, where we did this for the opposite case (allowing a window with an opener to process swap on a cross-origin manual navigation). * Source/WebKit/UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigationInternal): * Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: Canonical link: https://commits.webkit.org/275565@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes