c6c32eb84a8d47e2a1967bc719db326e3f841b10  [Site Isolation] TestWebKitAPI.EnhancedSecurityPolicies.IframeKeepsSiteOutOfEnhancedSecurityProcessWithSiteIsolation crashes under shared process mode

[Site Isolation] TestWebKitAPI.EnhancedSecurityPolicies.IframeKeepsSiteOutOfEnhancedSecurityProcessWithSiteIsolation crashes under shared process mode
https://bugs.webkit.org/show_bug.cgi?id=324271
rdar://187492888

Reviewed by Alex Christensen.

The test crashes due to `ASSERT(&sharedProcess->process() == &process)` in BrowsingContextGroup::ensureProcessForSite.
Here's the test flow:
1. Page loads an HTML string with no base URL (so its URL is about:blank), which has an iframe of example.com
2. Page loads example.com

In shared process mode, a cross-site subframe goes to the BCG's shared process, so the subframe is in the shared
process, and "example.com" is in BrowsingContextGroup::m_sharedProcessSites. (Without shared process mode the
subframe stays in its parent's process here, and nothing conflicts.) In step2, browsingContextGroupForNavigation
decides the navigation should use a new BCG, so BrowsingContextGroup::sharedProcessForSite returns null (the new
group has no shared process, and a main frame never starts one), and then
WebProcessPool::processForNavigationInternal will kick in to pick a web process for navigation. It picks the source
process (the one loading the HTML string) and treats the navigation as same-site, because that process has only
committed about:blank and its site is still empty -- so the process is not swapped for the navigation.

In current implementation, if process is not swapped, the old BCG will be used since the BCG swap flow only exists
in provisional page load. The problem is, example.com is already in shared process of the old BCG, and now we pick
an isolated process for example.com. This is what leads to the assertion failure -- one site in two processes.

The current implementation does not support moving a site out of shared process, so to fix this issue, the patch
ensures to return a new process (so a process swap will happen and BCG can be swapped) in this specific case. A
longer-term solution might be having the capability to support swapping a site out of shared process mode, but that
would require a bigger change, and we'll still need a fallback when the swap is infeasible (e.g. there are
example.com frames in the shared process that belong to another page in the group).

Update EnhancedSecurityPolicies.IframeKeepsSiteOutOfEnhancedSecurityProcess to turn shared process mode off and add
a dedicated test for shared process mode. The two modes have different process models in this scenario, and that
changes whether the site can be moved into an enhanced security process when the response arrives: with the
subframe sharing the site's FrameProcess, frameCount() > 1 makes canMoveSiteToEnhancedSecurityProcess decline the
move, while in shared process mode the main frame only has a FrameProcess of its own and the move is allowed.

Test: EnhancedSecurityPolicies.IframeInSharedProcessDoesNotKeepSiteOutOfEnhancedSecurityProcess

* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::processForNavigation):
(WebKit::WebProcessPool::processForNavigationInternal):
* Source/WebKit/UIProcess/WebProcessPool.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/EnhancedSecurityPolicies.mm:
(enhancedSecurityTestConfiguration):
(iframeProcessIdentifier):
(runIframeKeepsSiteOutOfEnhancedSecurityProcess):
(TEST(EnhancedSecurityPolicies, IframeInSharedProcessDoesNotKeepSiteOutOfEnhancedSecurityProcess)):

Canonical link: https://commits.webkit.org/321270@main