[webkit-changes] [WebKit/WebKit] 7c33c6: Sever opener link for windows with an openee on ma...

[bnham]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7c33c64d1ef537430380dad36728614f7ce77e6c
      https://github.com/WebKit/WebKit/commit/7c33c64d1ef537430380dad36728614f7ce77e6c
  Author: Ben Nham <nham at 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 at 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