-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Editorial: similar-origin window agent #5444
Comments
I don't think the name is too bad as-is. It's already the case that a "similar-origin window agent" does not contain every realm with a similar origin, because of separation into different BCGs. #4734 just increase the number of cases where similar-origin realms end up in different agents. Stated another way, every realm inside the agent still has a similar origin to each other, so the name is still accurate. That said, we could just rename it window agent. That's nice and short. The main benefit of the current name is that it makes it really obvious to readers that it isn't a single window, but we have some notes explaining that already, and could add more if we thought it wasn't clear enough. |
Even if we keep the name, I should update some of the notes/examples to explain they're conditional on the surrounding agent cluster's cross-origin isolated. |
It now explains how it relates to cross-origin isolated. Closes #5444.
It now explains how it relates to cross-origin isolated. Closes #5444.
A top-level navigation response with Cross-Origin-Opener-Policy set to same-origin and Cross-Origin-Embedder-Policy set to require-corp will create a cross-origin isolated browsing context group. And all agent clusters therein will be cross-origin isolated as well (shared and service workers can still not be, as they sit on the side). This change also: * Gates SharedArrayBuffer exposure behind that primitive for web compatibility reasons. * Gates SharedArrayBuffer sharing behind that primitive. * Exposes it through self.crossOriginIsolated. * Makes document.domain return before it mutates the origin. * Makes agent clusters keyed on origin. Tests: * web-platform-tests/wpt#17719 * web-platform-tests/wpt#17760 * web-platform-tests/wpt#17761 * web-platform-tests/wpt#17802 * web-platform-tests/wpt#17909 * web-platform-tests/wpt#18543 * web-platform-tests/wpt#20116 * web-platform-tests/wpt#22358 Closes #4732. Closes #5122. Closes #5444. Follow-up: #5435.
A top-level navigation response with Cross-Origin-Opener-Policy set to same-origin and Cross-Origin-Embedder-Policy set to require-corp will create a cross-origin isolated browsing context group. And all agent clusters therein will be cross-origin isolated as well (shared and service workers can still not be, as they sit on the side). This change also: * Gates SharedArrayBuffer exposure behind that primitive for web compatibility reasons. * Gates SharedArrayBuffer sharing behind that primitive. * Exposes it through self.crossOriginIsolated. * Makes document.domain return before it mutates the origin. * Makes agent clusters keyed on origin. Tests: * web-platform-tests/wpt#17719 * web-platform-tests/wpt#17760 * web-platform-tests/wpt#17761 * web-platform-tests/wpt#17802 * web-platform-tests/wpt#17909 * web-platform-tests/wpt#18543 * web-platform-tests/wpt#20116 * web-platform-tests/wpt#22358 Closes whatwg#4732. Closes whatwg#5122. Closes whatwg#5444. Follow-up: whatwg#5435 (and whatwg#5362).
With #4734 a similar-origin window agent might become a single-origin window agent. How do we want to handle this? I suspect we want to keep it as a single type for convenience. Should we change the name?
cc @domenic
The text was updated successfully, but these errors were encountered: