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
