Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sever opener link for windows with an openee on manual navigation #25253

Conversation

bnham
Copy link
Contributor

@bnham bnham commented Feb 28, 2024

7c33c64

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:

whatwg/html#5767 (comment)

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

edd3347

Misc iOS, tvOS & watchOS macOS Linux Windows
✅ 🧪 style ✅ 🛠 ios ✅ 🛠 mac ✅ 🛠 wpe ✅ 🛠 wincairo
✅ 🧪 bindings ✅ 🛠 ios-sim ✅ 🛠 mac-AS-debug 🧪 wpe-wk2
✅ 🧪 webkitperl ✅ 🧪 ios-wk2 ✅ 🧪 api-mac 🧪 api-wpe
✅ 🧪 ios-wk2-wpt ✅ 🧪 mac-wk1 ✅ 🛠 gtk
✅ 🧪 api-ios ✅ 🧪 mac-wk2 ✅ 🧪 gtk-wk2
✅ 🛠 tv ✅ 🧪 mac-AS-debug-wk2 ✅ 🧪 api-gtk
✅ 🛠 tv-sim
✅ 🛠 🧪 merge ✅ 🛠 watch
✅ 🛠 watch-sim

@bnham bnham requested a review from cdumez as a code owner February 28, 2024 22:11
@bnham bnham self-assigned this Feb 28, 2024
@bnham bnham added the WebKit Misc. For miscellaneous bugs in the WebKit framework (and not JavaScriptCore or WebCore). label Feb 28, 2024
Copy link
Contributor

@cdumez cdumez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@bnham bnham added the merge-queue Applied to send a pull request to merge-queue label Mar 1, 2024
@webkit-commit-queue webkit-commit-queue force-pushed the eng/Sever-opener-link-for-windows-with-an-openee-on-manual-navigation branch from edd3347 to 14c2d2f Compare March 1, 2024 20:54
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:

whatwg/html#5767 (comment)

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
@webkit-commit-queue webkit-commit-queue force-pushed the eng/Sever-opener-link-for-windows-with-an-openee-on-manual-navigation branch from 14c2d2f to 7c33c64 Compare March 1, 2024 20:57
@webkit-commit-queue
Copy link
Collaborator

Committed 275565@main (7c33c64): https://commits.webkit.org/275565@main

Reviewed commits have been landed. Closing PR #25253 and removing active labels.

@webkit-commit-queue webkit-commit-queue merged commit 7c33c64 into WebKit:main Mar 1, 2024
@webkit-commit-queue webkit-commit-queue removed the merge-queue Applied to send a pull request to merge-queue label Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WebKit Misc. For miscellaneous bugs in the WebKit framework (and not JavaScriptCore or WebCore).
Projects
None yet
4 participants