Remove the origin aliasing concept #868
Conversation
Origin serialization didn’t properly serialize hosts and ports and used the domain to Unicode and domain to ASCII algorithms incorrectly, passing domain labels rather than domains (not accounting for the fact that the host might not be a domain either). This depends on #868 landing since it assumes aliasing is no longer a thing. This also depends on the URL Standard changing to no longer pass the default port when computing the origin of a URL. Instead, an origin and a URL should share the same data model subset, where port can be null. Since they serialise the same way, that makes things easier to understand. This fixes #611, https://www.w3.org/Bugs/Public/show_bug.cgi?id=28788, and https://www.w3.org/Bugs/Public/show_bug.cgi?id=29056.
|
@jeisinger would you be willing to review this? |
|
yup, will have a closer look at this tomorrow |
| <code>Document</code></span>.</p></li> | ||
| <li> | ||
| <p>If the new <span>browsing context</span> has a <span>creator browsing context</span>, | ||
| then the <span>origin</span> of <var>document</var> is a copy of the <span>origin</span> of |
There was a problem hiding this comment.
why did you replace this with copy instead of sharing the origin with the creator browsing context?
There was a problem hiding this comment.
It felt cleaner since origin (as opposed to effective script origin) can never change, but I guess it doesn't matter much.
|
@domenic can you do follow up review here? (Jochen is otherwise occupied.) Note that per https://www.w3.org/Bugs/Public/show_bug.cgi?id=27378 I'm planning follow up fixes that will merge effective script origin into origin, to more closely match implementations and improve the readability of the specification (as well as the overall model). |
|
This looks good to me. I agree that copy vs. share is confusing. My preferred model would probably be that origin tuples are immutable and that document.domain reassigns the relevant documents' origins to a newly-created tuple. Then you can share with no fear. But based on #794 it sounds like that is not how implementations work. So your strategy of doing copies everywhere except where it's supposed to be explicitly shared seems like the best we can get. |
domenic
force-pushed
the
remove-origin-alias
branch
from
b9a7cf9
to
438155d
Compare
Turns out effective script origins are shared, not aliased. Fixes #794.
Origin serialization didn’t properly serialize hosts and ports and used the domain to Unicode and domain to ASCII algorithms incorrectly, passing domain labels rather than domains (not accounting for the fact that the host might not be a domain either). This depends on #868 landing since it assumes aliasing is no longer a thing. This also depends on the URL Standard changing to no longer pass the default port when computing the origin of a URL. Instead, an origin and a URL should share the same data model subset, where port can be null. Since they serialise the same way, that makes things easier to understand. See whatwg/url#102 for that. This fixes #611, https://www.w3.org/Bugs/Public/show_bug.cgi?id=28788, and https://www.w3.org/Bugs/Public/show_bug.cgi?id=29056.
Origin serialization didn’t properly serialize hosts and ports and used the domain to Unicode and domain to ASCII algorithms incorrectly, passing domain labels rather than domains (not accounting for the fact that the host might not be a domain either). This depends on #868 landing since it assumes aliasing is no longer a thing. This also depends on the URL Standard changing to no longer pass the default port when computing the origin of a URL. Instead, an origin and a URL should share the same data model subset, where port can be null. Since they serialise the same way, that makes things easier to understand. See whatwg/url#102 for that. This fixes #611, https://www.w3.org/Bugs/Public/show_bug.cgi?id=28788, and https://www.w3.org/Bugs/Public/show_bug.cgi?id=29056.
Turns out effective script origins are shared, not aliased.
Fixes #794.