Implement the Origin-Agent-Cluster header#66162
Conversation
|
EWS run on previous version of this PR (hash f5dd211) Details |
macOS Safer C++ Build #111505 (f5dd211)❌ Found 3 failing files with 5 issues. Please address these issues before landing. See WebKit Guidelines for Safer C++ Programming. |
iOS Safer C++ Build #30153 (f5dd211)❌ Found 3 failing files with 4 issues. Please address these issues before landing. See WebKit Guidelines for Safer C++ Programming. |
f5dd211 to
a910c5e
Compare
|
EWS run on previous version of this PR (hash a910c5e) Details |
| @@ -101,6 +111,8 @@ class BrowsingContextGroup : public RefCountedAndCanMakeWeakPtr<BrowsingContextG | |||
| HashMap<WebCore::Site, WeakPtr<FrameProcess>> m_processMap; | |||
| WeakListHashSet<WebPageProxy> m_pages; | |||
| WeakHashMap<WebPageProxy, HashSet<Ref<RemotePageProxy>>> m_remotePages; | |||
|
|
|||
| HashMap<WebCore::SecurityOriginData, WebCore::OriginKeyed> m_historicalAgentClusterKeyMap; | |||
There was a problem hiding this comment.
Could this just be a HashSet of origins that are origin keyed?
Are origins ever removed, or does this just grow for the lifetime of the BrowsingContextGroup?
There was a problem hiding this comment.
It grows for the lifetime of the BCG.
There was a problem hiding this comment.
And we can't use a set because we need to track:
- Not seen at all.
- Seen and origin-keyed.
- Seen and not origin-keyed.
Because we don't want to flip on the prior keying.
| void clearBrowsingContextGroupForTesting() | ||
| { | ||
| m_identifier = WebCore::BrowsingContextGroupIdentifier::generate(); | ||
| m_historicalAgentClusterKeyMap.clear(); |
There was a problem hiding this comment.
If we put this in BrowsingContextGroup.cpp we can probably remove the additional headers included from this header and use forward declarations instead.
There was a problem hiding this comment.
I will stop inlining it, but I can't forward declare anything new unless we wrap the HashMap in a unique_ptr which I suspect we don't want to do.
a910c5e to
3cfe28c
Compare
|
EWS run on previous version of this PR (hash 3cfe28c) Details |
| }); | ||
| } | ||
|
|
||
| void WKPageClearBrowsingContextGroupForTesting(WKPageRef pageRef) |
There was a problem hiding this comment.
I wonder if this would be better just added as part of WKPageResetStateBetweenTests
| OriginAgentClusterPolicy isolatedCopy() const & { return { isOriginKeyed }; } | ||
| OriginAgentClusterPolicy isolatedCopy() && { return { isOriginKeyed }; } |
There was a problem hiding this comment.
There doesn't seem to be a good reason to have a separate function for if it's an l-value or an r-value if they both are identical. Maybe we're planning to add strings here, I'm not sure.
There was a problem hiding this comment.
Yeah, I realized we can remove the entire struct for now so I went ahead and did that. Perhaps we need something more involved when we flip the default, but maybe not.
3cfe28c to
b06eacb
Compare
|
EWS run on current version of this PR (hash b06eacb) Details
|
https://bugs.webkit.org/show_bug.cgi?id=216618 rdar://69452369 Reviewed by Alex Christensen. This implements origin-keyed agent clusters and gates it behind OriginAgentClusterEnabled (set to preview). It is standardized here: https://html.spec.whatwg.org/multipage/browsers.html#origin-isolation This new keying does not impact process allocation, although we could decide to make it impact that in the future if we wanted to. It impacts document.domain, serialization and deserialization of certain objects, and the new window.originAgentCluster getter. We add a new test that is upstreamed at web-platform-tests/wpt#60311 that catches an issue with our existing agent cluster implementation for opaque origins and we also fix that issue. As the test infrastructure continues to use the same browsing context group for each test, we add a way to reset the browsing context group state so it appears as if you are getting a fresh browsing context group when you start a new test. The subtest failures of regression-1399759.https.sub.html are due to about:blank inheriting from the parent instead of the initiator of the navigation. That's a distinct issue from this new feature. going-back.sub.https.html is skipped because it times out on some bots at the history.back() step, while the feature-related assertions pass. I suspect it's related to the bfcache. I could not reproduce it locally (1000 iterations of the test as well as 10 full-directory runs). Canonical link: https://commits.webkit.org/314346@main
b06eacb to
b4c4069
Compare
|
Committed 314346@main (b4c4069): https://commits.webkit.org/314346@main Reviewed commits have been landed. Closing PR #66162 and removing active labels. |
🧪 api-ios
b4c4069
b06eacb
🧪 win-tests🧪 ios-wk2🧪 ios-wk2-wpt🧪 api-ios🛠 jsc-armv7🧪 jsc-armv7-tests