Define the "extract an origin" operation.

[mikewest]

whatwg/html#11846 added an Origin interface, which relies on an "extract an origin" operation to support the creation of new Origin objects via Origin.from(...). This PR defines that operation for URL objects.

Addresses a remaining portion of whatwg/html#11534.

• At least two implementers are interested (and none opposed):
  • [Origin API] Define an Origin interface. (#11534) html#11846 records the support for the underlying change.
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/html/browsers/origin/tentative/api/origin-from-url.any.html?label=experimental&label=master&aligned (will be non-tentative shortly).
• Implementation bugs are filed:
  • This work is part of the work necessary for the bugs recorded in the HTML PR above.
• MDN issue is filed: Same as the HTML PR above.
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

I think it's a little weird that we use "this" here, but it's probably okay.

[mikewest]

This mirrors what we did in HTML (e.g. https://html.spec.whatwg.org/multipage/browsers.html#the-origin-interface:extract-an-origin and https://html.spec.whatwg.org/multipage/webappapis.html#windoworworkerglobalscope-mixin:extract-an-origin). We could replace it with something like "the object's" throughout if that would be preferable?

[annevk]

WPT comments:

• You can't create new content in WPT /interfaces/. That directory is managed automatically. It should probably be tested as part of other html.idl APIs, though perhaps it can be split, but it'll have to load html.idl.
• It seems like we don't have tests for <a> and <area> without href attributes. From a quick skim I suspect this might not be implemented correctly.

[mikewest]

You can't create new content in WPT /interfaces/. That directory is managed automatically. It should probably be tested as part of other html.idl APIs, though perhaps it can be split, but it'll have to load html.idl.

You're right, I didn't think about this when we moved Origin into HTML. I'll fix it up once the file's updated (https://github.com/w3c/webref/blob/main/ed/idl/html.idl is up to date, but hasn't been pulled in yet...).

It seems like we don't have tests for <a> and <area> without href attributes. From a quick skim I suspect this might not be implemented correctly.

I can add those, thanks for the suggestion!

[mikewest]

It seems like we don't have tests for <a> and <area> without href attributes. From a quick skim I suspect this might not be implemented correctly.

I can add those, thanks for the suggestion!

You were right; Chromium's implementation was returning an opaque origin rather than throwing on Origin.from(<a>). Fixing that and updating the tests in https://chromium-review.googlesource.com/c/chromium/src/+/7231346.

[shannonbooth]

Something that I noticed is not covered by WPT (just incase this case was not considered in the design) is the below case:

let url = new URL('data:text/plain,opaque');
const origin1 = Origin.from(url);
const origin2 = Origin.from(url);
console.log(origin1.isSameOrigin(origin2));

Which from https://url.spec.whatwg.org/#concept-url-origin the result will be false:

-> Otherwise
Return a new opaque origin.

NOTE: This does indeed mean that these URLs cannot be same origin with themselves.

A similar case also happens for https://html.spec.whatwg.org/multipage/links.html#api-for-a-and-area-elements:extract-an-origin I believe.

I can make the updates to WPT, just thought I'd double check I have the right understanding, since I suppose it is possible to hold on to the origin for those objects to have different behaviour if-so desired

[annevk]

Yeah, we should test that and I think it should return false indeed.

[mikewest]

👍 I thought I'd added tests like that to https://wpt.fyi/results/html/browsers/origin/api/origin-comparison.any.html?label=master&label=experimental&aligned, but I didn't. If you have a PR, great! If not, I'll put one up this morning (as I need to fix the IDL test anyway).

[shannonbooth]

Nothing comprehensive so far unfortunately sorry! Only have so far the URL & hyperlink element case from hacking around my implementation locally. I haven't built up anything more comprehensive for the other cases like for WindowOrWorkerGlobal scope which seem like would be a bit different in that the ESO returns the same origin origin instance (besides from data URL workers, which create a new opaque one when callef).

[shannonbooth]

Sorry for the delay, I have been busy with day-job and other stuff lately rather than hacking on web-platform stuff like I would like to do, finally got around to raising something now web-platform-tests/wpt#56922

Edit: Unrelated question - but will this new section of the specification be linkable somehow? At least locally I can't figure out what such a link will end up being. For the HTML spec it's things like https://html.spec.whatwg.org/multipage/webappapis.html#windoworworkerglobalscope-mixin:extract-an-origin, but I only managed to find that from cross-links which doesn't work in the URL specification at a standalone document. Probably some other method of getting it I am missing though!

[annevk]

Now that the tests have landed let me merge this. There's still one outstanding issue surrounding MessageEvent and ExtendableMessageEvent but no need to block on that I think: whatwg/html#11993.