Calculate ancestorOrigins on document creation and store on document by zcorpan · Pull Request #12071 · whatwg/html

zcorpan · 2026-01-09T14:11:52Z

When a Location object is created, a Document is not yet created. This is problematic for ancestorOrigins.

Also remove [SameObject] since step 1 can return a separate object.

At least two implementers are interested (and none opposed):
- Gecko
- ...
Tests are written and can be reviewed and commented upon at:
- HTML: Test that location.ancestorOrigins is not [SameObject] web-platform-tests/wpt#56635
- https://wpt.fyi/results/html/browsers/history/the-location-interface/location-ancestor-origins-inactive-document.sub.html?label=experimental&label=master&aligned
Implementation bugs are filed:
- Chromium: N/A
- Gecko: N/A
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=305922
Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
MDN issue is filed: N/A
The top of this comment includes a clear commit message to use.
Affected specs
- Update 'ancestor origins list' xref w3c/ServiceWorker#1812

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

/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/dom.html ( diff )
/index.html ( diff )
/nav-history-apis.html ( diff )

When a Location object is created, a Document is not yet created. This is problematic for ancestorOrigins.

domfarolino

I think this looks great, thanks! I have a question about the implications of moving from Location/Window to Document, since these are not always 1:1.

Example: you navigate an iframe from the initial about:blank Document to a same-origin one. I think neither the inner Window nor Location objects change, yet this PR would recalculate ancestor origins after the navigation, where as the current spec would not. Is that ever observable?

I envisioned a case where an iframe's ancestor used document.domain to change its origin before the navigation away from the initial about:blank Document. The current spec would not reflect the ancestor's origin change, since ancestorOrigins never gets recalculated. After this PR, the new document's ancestor origins list gets recalculated to its ancestor's "ancestor origins list" plus the ancestor's origin, which could have changed. On the other hand, we only ever expose its ASCII serialization, which never considers an origin's domain, so I guess it's not observable.

So basically after this PR, in the navigation scenario I described above, the "internal ancestor origins objects list" CAN change, but not in a way that is observable to script. Is that right?

Edit: Regarding the PR template, if there is indeed no observable change here, maybe the "At least two implementers are interested (and none opposed):" becomes "N/A"?

domfarolino · 2026-01-20T17:43:30Z

source

+   <li><p><span data-x="list append">Append</span> <var>parentDoc</var>'s <span
+   data-x="concept-document-origin">origin</span> to <var>output</var>.</p></li>
+
+   <li>


Maybe we could use https://infra.spec.whatwg.org/#list-extend, instead of iterating manually?

#11560 would need to change back to iterating the list though.

zcorpan · 2026-01-21T10:13:03Z

Without the referrerpolicy change I think there's no observable difference. Even with document.domain, that doesn't change the origin returned by ancestorOrigins because https://html.spec.whatwg.org/#ascii-serialisation-of-an-origin seralizes the origin's host, not the origin's domain (demo). There's no other way for the parent document to change its origin or its sandboxing flags after the document is created AFAIK.

There is an observable difference here though which is [SameObject] removal and returning a new DOMTokenList every time (which matches Chromium and Gecko but not WebKit). This is tested in https://wpt.fyi/results/html/browsers/history/the-location-interface/location-ancestor-origins-inactive-document.sub.html?label=experimental&label=master&aligned and web-platform-tests/wpt#56635

domfarolino · 2026-01-21T13:13:40Z

There's no other way for the parent document to change its origin or its sandboxing flags after the document is created AFAIK.

Right, well technically it changes its origin by virtue of changing its origin's domain with document.domain, but this doesn't impact same origin checks, only same origin-domain checks I guess. Does that match your understanding?

Even with #11560, there should be no observable change due to document.domain, because #11560 only ever refers to "same origin" checks, never "same origin-domain" checks. Is this right?

zcorpan · 2026-01-21T16:09:01Z

Yes, correct. Though with #11560 you can have an iframe with the initial about:blank document, then change the referrerpolicy attribute, then navigate the iframe. The Location object is the same, but ancestorOrigins is different for the two documents. See https://wpt.fyi/results/html/browsers/history/the-location-interface/location-ancestor-origins-referrerpolicy-snapshot.html?label=experimental&label=master&aligned

zcorpan · 2026-01-21T16:13:39Z

@annevk is this OK for WebKit?

This term is now a list (not a DOMTokenList) on Document (not Location). See whatwg/html#12071

annevk · 2026-01-23T07:21:47Z

source

@@ -97027,7 +96869,7 @@ interface <dfn interface>Location</dfn> { // but see also <a href="#the-location
  [<span>LegacyUnforgeable</span>] undefined <span data-x="dom-location-replace">replace</span>(USVString url);
  [<span>LegacyUnforgeable</span>] undefined <span data-x="dom-location-reload">reload</span>();

-  [<span>LegacyUnforgeable</span>, SameObject] readonly attribute <span>DOMStringList</span> <span data-x="dom-location-ancestorOrigins">ancestorOrigins</span>;
+  [<span>LegacyUnforgeable</span>] readonly attribute <span>DOMStringList</span> <span data-x="dom-location-ancestorOrigins">ancestorOrigins</span>;


Not returning the same object each time from a getter seems very surprising. Why would we want that? You don't want obj.x !== obj.x (there's a rule for this in the design principles as well).

Step 1 says to return a an empty DOMStringList if this's relevant Document is null.

Since the relevant Document can change over time, I think we can't return the same object always. So options are:

Cache whatever was returned the first time the getter is called. (This matches WebKit.)

Return a new object every time. (Gecko, Chromium.)

Maybe throw an InvalidStateError in step 1?

The current spec is wrong since it says SameObject but then in step 1 sometimes returns an empty list (not a DOMStringList).

We don't have to return the same object always to not violate obj.x !== obj.x. Caching or throwing would work. Caching is probably the most compatible. SameObject is indeed wrong if the returned value has to change at certain points in time though.

Can you observe the object changing in WebKit? Maybe with initial about:blank?

Yes, for example removing an iframe. But since WebKit caches the return value from the first access, it's different if you call the getter first before or after the iframe is removed.

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14480

Maybe option 4 is to create an empty DOMStringList in step 1 but cache it, so there can be two separate objects returned.

I think if you navigate an iframe its Location object stays the same, but the relevant Document changes as well. (Even across a cross-origin navigation I'm pretty sure as you're holding a proxy object, essentially.) We probably want to invalidate the list each time the relevant Document changes. Not a 100% sure how to best specify this though.

This PR computes a new list when a Document is created and stores it on the Document object, so that is solved by this PR.

About the chaching or throwing issue, should we go with option 4?

I don't quite follow here. If iframe can be removed, the location have it's relevant document null, then

let a = location.ancestorOrigins; ... /* relevant document for location becomes null */ ... let b = location.ancestorOrigins; a !== b; // true

Also

let loc = i.location; let list = loc.ancestorOrigins; i.contentWindow.navigation.navigate("www.some.where.else-same-origin.com"); let whatIsThis = list !== loc.ancestorOrigins;

What value does whatIsThis have?

Is there a reason why we can't make this attribute NewObject?

@theIDinside it's ok to have a new object when there's a semantic change, but just accessing ancestorOrigins twice without removing an iframe or navigating should give the same object both times.

OK I've attempted to fix this in e3091d3

web-platform-tests/wpt#56635 updated also.

Calculate ancestorOrigins on document creation and store on document

bef57e1

When a Location object is created, a Document is not yet created. This is problematic for ancestorOrigins.

zcorpan requested a review from domfarolino January 9, 2026 14:11

zcorpan mentioned this pull request Jan 9, 2026

Redact ancestorOrigins using iframe referrerpolicy #11560

Open

6 tasks

domfarolino approved these changes Jan 20, 2026

View reviewed changes

Export dfns

6bf7fe6

zcorpan added a commit to zcorpan/ServiceWorker that referenced this pull request Jan 22, 2026

Update 'ancestor origins list' xref

45f764f

This term is now a list (not a DOMTokenList) on Document (not Location). See whatwg/html#12071

zcorpan mentioned this pull request Jan 22, 2026

Update 'ancestor origins list' xref w3c/ServiceWorker#1812

Open

annevk reviewed Jan 23, 2026

View reviewed changes

Don't return a new object every time

e3091d3

Conversation

zcorpan commented Jan 9, 2026 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

domfarolino left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zcorpan commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

domfarolino commented Jan 21, 2026

Uh oh!

zcorpan commented Jan 21, 2026

Uh oh!

zcorpan commented Jan 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

zcorpan commented Jan 9, 2026 •

edited by pr-preview bot

Loading

domfarolino left a comment •

edited

Loading

zcorpan commented Jan 21, 2026 •

edited

Loading