2022-04-22 Russell Epstein Cherry-pick r291589. rdar://problem/90511155 LayoutTests/imported/w3c: BroadcastChannel instances in distinct opaque origins can communicate https://bugs.webkit.org/show_bug.cgi?id=238090 Reviewed by Alex Christensen. Import web-platform-tests test coverage. * web-platform-tests/webmessaging/broadcastchannel/opaque-origin-expected.txt: Added. * web-platform-tests/webmessaging/broadcastchannel/opaque-origin.html: Added. * web-platform-tests/webmessaging/broadcastchannel/w3c-import.log: Source/WebCore: BroadcastChannel instances in distinct opaque origins can communicate https://bugs.webkit.org/show_bug.cgi?id=238090 Reviewed by Alex Christensen. The issue is that we would use a ClientOrigin to distinguish origins for BroadcastChannel, which relies on SecurityOriginData internally. A unique/opaque SecurityOrigin becomes an empty SecurityOriginData upon conversion. As a result, when comparing ClientOrigin objects from unique SecurityOrigins, they would compare as equal. To address the issue, I introduced a new PartitionedSecurityOrigin type which is similar to ClientOrigin but stores SecurityOrigin objects internally, instead of SecurityOriginData objects. PartitionedSecurityOrigin's operator==() is such that different SecurityOrigins would not be equal but the same unique SecurityOrigin would be. I then used this new PartitionedSecurityOrigin type as key in our HashMap on the WebProcess side instead of ClientOrigin. This allows communication between several BroadcastChannels from the same unique origin, while preventing communication between distinct opaque origins. When the PartitionedSecurityOrigin contains an opaque security origin, we don't involve the Network Process at all since the destination can only be in the same WebProcess. Test: imported/w3c/web-platform-tests/webmessaging/broadcastchannel/opaque-origin.html * Headers.cmake: * WebCore.xcodeproj/project.pbxproj: * dom/BroadcastChannel.cpp: (WebCore::shouldPartitionOrigin): (WebCore::BroadcastChannel::MainThreadBridge::registerChannel): (WebCore::BroadcastChannel::MainThreadBridge::unregisterChannel): (WebCore::BroadcastChannel::MainThreadBridge::postMessage): * dom/BroadcastChannelRegistry.h: * loader/EmptyClients.cpp: * page/PartitionedSecurityOrigin.h: Added. (WebCore::PartitionedSecurityOrigin::PartitionedSecurityOrigin): (WebCore::PartitionedSecurityOrigin::isHashTableDeletedValue const): (WebCore::PartitionedSecurityOrigin::isHashTableEmptyValue const): (WebCore::operator==): (WTF::add): (WTF::PartitionedSecurityOriginHash::hash): (WTF::PartitionedSecurityOriginHash::equal): (WTF::HashTraits::emptyValue): (WTF::HashTraits::constructEmptyValue): (WTF::HashTraits::isEmptyValue): (WTF::HashTraits::peek): (WTF::HashTraits::take): Source/WebKit: BroadcastChannel instances in distinct opaque origins can communicate https://bugs.webkit.org/show_bug.cgi?id=238090 Reviewed by Alex Christensen. The issue is that we would use a ClientOrigin to distinguish origins for BroadcastChannel, which relies on SecurityOriginData internally. A unique/opaque SecurityOrigin becomes an empty SecurityOriginData upon conversion. As a result, when comparing ClientOrigin objects from unique SecurityOrigins, they would compare as equal. To address the issue, I introduced a new PartitionedSecurityOrigin type which is similar to ClientOrigin but stores SecurityOrigin objects internally, instead of SecurityOriginData objects. PartitionedSecurityOrigin's operator==() is such that different SecurityOrigins would not be equal but the same unique SecurityOrigin would be. I then used this new PartitionedSecurityOrigin type as key in our HashMap on the WebProcess side instead of ClientOrigin. This allows communication between several BroadcastChannels from the same unique origin, while preventing communication between distinct opaque origins. When the PartitionedSecurityOrigin contains an opaque security origin, we don't involve the Network Process at all since the destination can only be in the same WebProcess. * WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.cpp: (WebKit::toClientOrigin): (WebKit::WebBroadcastChannelRegistry::registerChannel): (WebKit::WebBroadcastChannelRegistry::unregisterChannel): (WebKit::WebBroadcastChannelRegistry::postMessage): (WebKit::WebBroadcastChannelRegistry::postMessageLocally): (WebKit::WebBroadcastChannelRegistry::postMessageToRemote): (WebKit::WebBroadcastChannelRegistry::networkProcessCrashed): * WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.h: Source/WebKitLegacy: Dust off Mac CMake build https://bugs.webkit.org/show_bug.cgi?id=238121 Reviewed by Yusuke Suzuki. * PlatformMac.cmake: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@291589 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2022-03-21 Chris Dumez BroadcastChannel instances in distinct opaque origins can communicate https://bugs.webkit.org/show_bug.cgi?id=238090 Reviewed by Alex Christensen. The issue is that we would use a ClientOrigin to distinguish origins for BroadcastChannel, which relies on SecurityOriginData internally. A unique/opaque SecurityOrigin becomes an empty SecurityOriginData upon conversion. As a result, when comparing ClientOrigin objects from unique SecurityOrigins, they would compare as equal. To address the issue, I introduced a new PartitionedSecurityOrigin type which is similar to ClientOrigin but stores SecurityOrigin objects internally, instead of SecurityOriginData objects. PartitionedSecurityOrigin's operator==() is such that different SecurityOrigins would not be equal but the same unique SecurityOrigin would be. I then used this new PartitionedSecurityOrigin type as key in our HashMap on the WebProcess side instead of ClientOrigin. This allows communication between several BroadcastChannels from the same unique origin, while preventing communication between distinct opaque origins. When the PartitionedSecurityOrigin contains an opaque security origin, we don't involve the Network Process at all since the destination can only be in the same WebProcess. * WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.cpp: (WebKit::toClientOrigin): (WebKit::WebBroadcastChannelRegistry::registerChannel): (WebKit::WebBroadcastChannelRegistry::unregisterChannel): (WebKit::WebBroadcastChannelRegistry::postMessage): (WebKit::WebBroadcastChannelRegistry::postMessageLocally): (WebKit::WebBroadcastChannelRegistry::postMessageToRemote): (WebKit::WebBroadcastChannelRegistry::networkProcessCrashed): * WebProcess/WebCoreSupport/WebBroadcastChannelRegistry.h: 2022-04-22 Russell Epstein Apply patch. rdar://problem/91446317 2022-04-21 Youenn Fablet Website policies are not respected when doing COOP based process swap https://bugs.webkit.org/show_bug.cgi?id=238036 Reviewed by Chris Dumez. In case of normal process swap, we make use of website policies so everything is fine. For COOP based process swap, this happens later on, at a point where we lost website policies. To overcome this, we store the website policies used by a navigation inside the API::Navigation object. It is used by continueNavigationInNewProcess to correctly initialize the new WebPage website policies. We then set the website policies in the navigation object just before continuing the load in the same process, as process swap may happen later when inspecting the response. Minor refactoring in continueNavigationInNewProcess to get the policies directly from the given Navigation object. Minor refactoring in receivedNavigationPolicyDecision to make the code doing process swap clearer. Covered by API test. * UIProcess/API/APINavigation.h: (API::Navigation::setWebsitePoliciesForProcessSwap): (API::Navigation::takeWebsitePoliciesForProcessSwap): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::receivedPolicyDecision): (WebKit::WebPageProxy::continueNavigationInNewProcess): (WebKit::WebPageProxy::triggerBrowsingContextGroupSwitchForNavigation): * UIProcess/WebPageProxy.h: 2022-04-22 Russell Epstein Apply patch. rdar://problem/91288849 2022-04-21 Youenn Fablet In case of COOP-based process swap, we need to make sure the document gets controlled by its matching service worker registration https://bugs.webkit.org/show_bug.cgi?id=238800 Reviewed by Chris Dumez. Make sure in case loader is transferred to call controlClient in the new WebProcess. To do so, we also update page and frame IDs. Covered by API test. * NetworkProcess/NetworkConnectionToWebProcess.cpp: * NetworkProcess/NetworkLoadParameters.h: * NetworkProcess/NetworkResourceLoadParameters.h: * NetworkProcess/NetworkResourceLoader.cpp: * NetworkProcess/NetworkResourceLoader.h: * NetworkProcess/ServiceWorker/WebSWServerConnection.cpp: * NetworkProcess/ServiceWorker/WebSWServerConnection.h: 2022-04-22 Russell Epstein Cherry-pick r291724. rdar://problem/91975589 Expose the AX tree of PDFs loaded via iframes on the Mac https://bugs.webkit.org/show_bug.cgi?id=238168 Reviewed by Chris Fleizach. Source/WebKit: Given this markup: