Redact ancestorOrigins using iframe referrerpolicy by zcorpan · Pull Request #11560 · whatwg/html

zcorpan · 2025-08-14T11:10:20Z

This aligns ancestorOrigins exposure with referrer policy when using the iframe referrerpolicy attribute, so an embedder can prevent revealing its own origin to embedded documents. If an <iframe> uses referrerpolicy="no-referrer" or same-origin (and the parent and child are cross-origin), the parent’s origin and any same-origin ancestors are replaced with opaque origins (until reaching an ancestor that is cross-origin). Other policies continue to expose full origins. ~~If there's no referrerpolicy attribute, the embedder document's referrer policy is used.~~

This approach keeps existing behavior by default (for web compat) while addressing privacy concerns with an opt-out.

The algorithm reuses the parent's existing list of ancestor origins, avoiding synchronous cross-process lookups and ensuring a stable snapshot even if ancestors mutate their referrerpolicy attributes later.

Fixes #1918. Closes #2480.

At least two implementers are interested (and none opposed):
- Gecko
- WebKit
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/u/1/issues/465806326
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=303537
Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
MDN issue is filed: Document that iframe referrerpolicy can influence location.ancestorOrigins and windowclient.ancestorOrigins mdn/content#42231
The top of this comment includes a clear commit message to use.

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

/browsers.html ( diff )
/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/dom.html ( diff )
/iframe-embed-object.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/nav-history-apis.html ( diff )

zcorpan · 2025-08-14T11:12:51Z

This is the same as @annevk's #2480 but applied on top of the latest main. Rebasing involved a lot of unrelated conflicts, so instead I copied over the content in a new branch.

annevk · 2025-08-14T12:52:12Z

I think using the document's referrer is the wrong model. Because we don't care about the referrer of top-level example.com (how the user got to example.com, perhaps from search.example), we care about example.com's policy (or its iframe's policy) when embedding widget.example, when determining what information widget.example should have access to.

source

zcorpan · 2025-08-14T17:07:02Z

I created a doc to work out how to specify this with the new model: https://docs.google.com/document/d/1TDryRMiw7sVKBfrvnzEQk0PzGQk7_G7ShF4Uy68MvSU/edit?usp=sharing

Copy of the doc's current state

Example 1

example.org (no referrer policy)
- Iframe referrerpolicy=”no-referrer”
  - Widget.example

Result: [“https://widget.example”, “null”]

Example 2

example.org (no referrer policy)
- Iframe referrerpolicy=”no-referrer”
  - Widget.example and navigates to other.example

Result: ???

Algo

HTML:

Let output be a new list of strings.
Let currentDoc be the Location object's relevant Document.
Let innerDoc be current.
Let currentContainer be null.
While currentDoc’'s container document is non-null:
1. Set currentContainer to current’s node navigable’s container.
2. Set currentDoc to current's container document.
3. Let origin be the result of getting an origin if the referrer policy allows given currentContainer, currentDoc, and innerDoc.
4. Append the serialization of current's origin to output.
Return output.

Referrer Policy:

To get an origin if the referrer policy allows given an element or null container, a document doc, and a document innerDoc:

Let elementReferrerPolicy be the empty string.
If element is not null, then set elementReferrerPolicy to element’s referrerpolicy attribute’s state.
Let docReferrerPolicy be doc’s referrer policy.
Let referrerPolicy be elementReferrerPolicy.
If referrerPolicy is the empty string, then set referrerPolicy to docReferrerPolicy.
If referrerPolicy is “no-referrer”, then return “null”.
If referrerPolicy is “same-origin” and doc’s origin is not same origin with innerDoc’s origin, then return “null”.
If referrerPolicy is “strict-origin”, "strict-origin-when-cross-origin", “no-referrer-when-downgrade”, and innerDoc’s URL is not potentially trustworthy but doc’s URL is potentially trustworthy, then return “null”.
Return the serialization of doc’s origin.

zcorpan · 2025-09-01T14:25:02Z

Doc updated. I've changed the algorithm to avoid exposing A's origin in the A->A->C case with the innermost iframe having referrerpolicy="no-referrer". Also added examples from w3c/webappsec-referrer-policy#77 (comment) and a polyfill to test with.

Copy of the doc's current state

Algorithm

HTML:

Let output be a new list of strings.
Let currentDoc be the Location object's relevant Document.
Let innerDoc be currentDoc.
Let currentContainer be null.
Let prevOrigin and prevMasked be uninitialized.
While currentDoc’s container document is non-null:
1. Set currentContainer to currentDoc’s node navigable’s container.
2. Set currentDoc to currentDoc's container document.
3. Let « origin, masked » be the result of [=getting an ancestor origin if the referrer policy allows=] given currentContainer, currentDoc, and innerDoc.
4. If prevMasked is true and origin is same origin with prevOrigin, then set masked to true.
5. If masked is true, then append “null” to output.
6. Otherwise, append the serialization of origin to output.
7. Set prevOrigin to origin.
8. Set prevMasked to masked.
Return output.

Referrer Policy:

To get an ancestor origin if the referrer policy allows given an Element container, a Document doc, and a Document innerDoc:

Let elementReferrerPolicy be the empty string.
If container is an iframe element, then set elementReferrerPolicy to container’s referrerpolicy attribute’s state.
Let docReferrerPolicy be doc’s policy container’s referrer policy.
Let referrerPolicy be elementReferrerPolicy.
If referrerPolicy is the empty string, then set referrerPolicy to docReferrerPolicy.
Let masked be false.
If referrerPolicy is “no-referrer”, then set masked to true.
Otherwise, if referrerPolicy is “same-origin” and doc’s origin is not same origin with innerDoc’s origin, then set masked to true.
Return « doc’s origin, masked ».

Note: Since mixed content checks prevent non-secure context documents in secure context documents, there’s no need to check secure context for “strict-origin”, "strict-origin-when-cross-origin", and “no-referrer-when-downgrade”.

Polyfill + demo

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

Examples

iframe referrerpolicy=”no-referrer”

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe referrerpolicy=”no-referrer”, origin: https://b.com

Child: ["null"]

Examples below are from w3c/webappsec-referrer-policy#77 (comment)

top -> sandboxed iframe -> 3rd party iframe (ad)

Top-level browsing context, default referrer policy, origin: https://a.com
- Iframe sandbox, origin: opaque
  - Iframe, origin: https://b.com

Grandchild: ["null","https://a.com"]
Child: ["https://a.com"]

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe referrerpolicy=”no-referrer”, origin: https://b.com
  - iframe, origin: https://a.com

Grandchild: ["https://b.com","null"]
Child: ["null"]

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - Iframe referrerpolicy=”no-referrer”, origin: https://a.com

Grandchild: ["null","https://a.com"]
Child: ["https://a.com"]

{1, a.com} default referrer policy -> loads {2, a.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, c.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://a.com
  - iframe referrerpolicy=”no-referrer”, origin: https://c.com

Grandchild: ["null","null"]
Child: ["https://a.com"]

{1, a.com} default referrer policy -> loads {2, b.com} with default referrer policy -> loads {3, b.com} with noreferrer attribute on the iframe tag inside {3} -> loads {4, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - iframe, origin: https://b.com
    - iframe referrerpolicy=”no-referrer”, origin: https://a.com

Grandgrandchild: ["null","null","https://a.com"]
Grandchild: ["https://b.com","https://a.com"]
Child: ["https://a.com"]

zcorpan · 2025-09-02T11:39:31Z

After discussing with @farre we found out that reading the iframe's referrerpolicy attribute every time ancestorOrigins is read is not great. Instead, the value of the referrerpolicy attribute should be read when the document is created and stored on the document (or in its policy container).

zcorpan · 2025-09-05T10:01:26Z

reading the iframe's referrerpolicy attribute every time ancestorOrigins is read is not great.

This was not correct, the spec computes the ancestor origins list when the Location object is created, which happens when the Window object is created.

When a Location object is created, its ancestor origins list must be set to a DOMStringList object whose associated list is the list of strings that the following steps would produce:

https://html.spec.whatwg.org/#concept-location-ancestor-origins-list

Each Window object is associated with a unique instance of a Location object, allocated when the Window object is created.

https://html.spec.whatwg.org/#the-location-interface

So no need to store iframe's referrerpolicy. However, we want to minimize IPC and avoid inconsistency e.g. when an ancestor iframe's referrerpolicy attribute is mutated and a new child iframe is inserted (or is navigated). So the model we came up with now is to take the parent's ancestor origins list, mask some values as appropriate, and insert a new value.

Copy of the doc's current state

Algorithm

A Location object has an associated ancestor origin objects list. When a Location object is created, its ancestor origins list must be set to the list of origins that the following steps would produce:

Let output be a new list of origins.
Let innerDoc be the Location object's relevant Document.
Let parentDoc be innerDoc’s container document.
If parentDoc is non-null:
1. Assert: parentDoc is fully active.
2. Let parentLocation be parentDoc’s relevant global object’s Location object.
3. Let ancestorOrigins be parentLocation’s ancestor origins list’s associated list.
4. Let container be innerDoc’s node navigable’s container.
5. Let referrerpolicyAttribute be the empty string.
6. If container supports a referrer policy attribute (e.g., container is an iframe element), then set referrerpolicyAttribute to container’s referrer policy attribute’s state.
7. Let docReferrerPolicy be parentDoc’s policy container’s referrer policy.
8. Let referrerPolicy be referrerpolicyAttribute.
9. If referrerPolicy is the empty string, then set referrerPolicy to docReferrerPolicy.
10. Let masked be false.
11. If referrerPolicy is “no-referrer”, then set masked to true.
12. Otherwise, if referrerPolicy is “same-origin” and parentDoc’s origin is not same origin with innerDoc’s origin, then set masked to true.
13. If masked is true, then append “null” to output.
14. Otherwise, append parentDoc’s origin to output.
15. For each ancestorOrigin in ancestorOrigins:
  1. If masked is true:
    1. If ancestorOrigin is same origin with parentDoc’s origin, then append a new opaque origin to output.
    2. Otherwise, append ancestorOrigin to output and set masked to false.
  2. Otherwise, append ancestorOrigin to output.
Return output.

Note: Since mixed content checks prevent non-secure context documents in secure context documents, there’s no need to check secure context for “strict-origin”, "strict-origin-when-cross-origin", and “no-referrer-when-downgrade”.

A Location object has an associated ancestor origins list. When a Location object is created, its ancestor origins list must be set to a DOMStringList object whose associated list is the list of strings the following steps would produce:

Let ancestorOrigins be this’s ancestor origin objects list.
Let output be a new list of strings.
For each origin in ancestorOrigins:
1. Append the serialization of origin to output.
Return output.

Polyfill + demo

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

Examples

iframe referrerpolicy=”no-referrer”

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe referrerpolicy=”no-referrer”, origin: https://b.com

Child: ["null"]

{1, a.com} default referrer policy -> loads {2, b.com} -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - iframe, origin: https://c.com

Grandchild: ["https://b.com","https://a.com"\]
Child: ["https://a.com"\]

Examples below are from w3c/webappsec-referrer-policy#77 (comment)

top -> sandboxed iframe -> 3rd party iframe (ad)

Top-level browsing context, default referrer policy, origin: https://a.com
- Iframe sandbox, origin: opaque
  - Iframe, origin: https://b.com

Grandchild: ["null","https://a.com"\]
Child: ["https://a.com"\]

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe referrerpolicy=”no-referrer”, origin: https://b.com
  - iframe, origin: https://a.com

Grandchild: ["https://b.com","null"\]
Child: ["null"]

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - Iframe referrerpolicy=”no-referrer”, origin: https://a.com

Grandchild: ["null","https://a.com"\]
Child: ["https://a.com"\]

{1, a.com} default referrer policy -> loads {2, a.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, c.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://a.com
  - iframe referrerpolicy=”no-referrer”, origin: https://c.com

Grandchild: ["null","null"]
Child: ["https://a.com"\]

{1, a.com} default referrer policy -> loads {2, b.com} with default referrer policy -> loads {3, b.com} with noreferrer attribute on the iframe tag inside {3} -> loads {4, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - iframe, origin: https://b.com
    - iframe referrerpolicy=”no-referrer”, origin: https://a.com

Grandgrandchild: ["null","null","https://a.com"\]
Grandchild: ["https://b.com","https://a.com"\]
Child: ["https://a.com"\]

TODOs

Test https://w3c.github.io/ServiceWorker/#client-ancestororigins

zcorpan · 2025-09-08T07:52:35Z

I've updated this PR, the algorithm should be the same as in the doc.

source

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Due to the tentative nature of the spec, and details still being hashed out, this PR is subject to minor changes.

This follows the current revamping of the spec found at whatwg/html#11560 and will change with it, potentially.

zcorpan · 2025-10-08T13:40:06Z

I wrote a summary of what this change does in the OP. (To be used in the commit message when squashing.)

noamr · 2025-10-13T15:35:00Z

cc @domfarolino

source

annevk · 2025-10-23T17:05:17Z

Before I forget: we need to patch https://w3c.github.io/ServiceWorker/#client-ancestororigins at the same time.

This aligns `ancestorOrigins` exposure with referrer policy, so an embedder can prevent revealing its own origin to embedded documents. If an `<iframe>` uses `referrerpolicy="no-referrer"` or `same-origin` (and the parent and child are cross-origin), the parent’s origin and any same-origin ancestors are replaced with opaque origins (until reaching an ancestor that is cross-origin). Other policies continue to expose full origins. If there's no `referrerpolicy` attribute, the embedder document's referrer policy is used. This approach keeps existing behavior by default (for web compat) while addressing privacy concerns with an opt-out. The algorithm reuses the parent's existing list of ancestor origins, avoiding synchronous cross-process lookups and ensuring a stable snapshot even if ancestors mutate their `referrerpolicy` attributes later. Fixes #1918. Closes #2480.

zcorpan · 2025-10-27T21:59:55Z

@annevk as far as I can tell, the call sites for Create Window Client use a Location object's ancestor origins list, which is still defined and compatible with this PR. But we should have tests for it.

johannhof · 2025-11-07T05:41:31Z

What is the reason for using the referrer policy instead of a new attribute / header? Are we not concerned that this would lead to situations where one of the two features is required, making it impossible for sites to opt out of the other?

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Due to the tentative nature of the spec, and details still being hashed out, this PR is subject to minor changes.

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 gecko-commit: 626bfdb90f3e1a0f78c6a6e832697520396e66bf gecko-reviewers: necko-reviewers, webidl, dom-core, smaug, jesup, zcorpan

zcorpan · 2025-12-19T13:05:32Z

source

+   <li><p>Let <var>innerDoc</var> be <var>location</var>'s <span>relevant
   <code>Document</code></span>.</p></li>


When a Location object is created, a Document does not yet exist, so relevant Document will be null here. Solution: run these steps after a Document is created.

zcorpan · 2025-12-19T13:08:06Z

source

+   <li><p>Set <var>location</var>'s <span
+   data-x="concept-internal-location-ancestor-origin-objects-list">internal ancestor origin objects
+   list</span> to the result of running the <span>internal ancestor origin objects list creation
+   steps</span> given <var>location</var>.</p></li>


Running these steps only when a Location object is created means that the list is not updated when navigating an iframe from initial about:blank to something else, if the referrerpolicy attribute was mutated in between (before navigation start).

Solution: run these steps when a Document is created, and store the list on Document.

This fixes the fact that "relevant Document" is not yet set when a Location is created, and that the list should be updated when navigating from initial about:blank (where the Window and Location is the same but a new Document is created).

domfarolino · 2025-12-19T15:58:14Z

source

+    data-x="environment">environments</span>, there's no need to check <span>secure context</span>
+    for "<code data-x="">strict-origin</code>", "<code
+    data-x="">strict-origin-when-cross-origin</code>", and "<code
+    data-x="">no-referrer-when-downgrade</code>".</p>


I wonder if we should pile onto this by mentioning that we also don't need to check for origin-when-cross-origin, since that would only restrict the referrer to the origin, which is already the most amount of information that ancestorOrigins exposes. It's kind of obvious, but I find myself thinking through it every time I review this PR heh.

domfarolino · 2025-12-19T16:18:51Z

source

+  <h4><code>iframe</code> referrer policy</h4>
+
+  <div algorithm>
+  <p>To <dfn data-x="determining the iframe referrer policy">determine the <code>iframe</code> referrer policy</dfn> given null or an element <var>embedder</var>:</p>


nit: I slightly prefer the pattern element-or-null

source

domfarolino · 2025-12-19T16:53:49Z

source

   <dt><dfn data-x="navigation-params-sandboxing">final sandboxing flag set</dfn></dt>
   <dd>a <span>sandboxing flag set</span> to impose on the new <code>Document</code></dd>

+   <dt><dfn data-x="navigation-params-iframe-referrer-policy"><code>iframe</code> referrer


I'm noticing that this is only set in a single place, and it's in the "response"-is-null path which is used for object/embed and x-mixed-replace, which means this line is technically doing nothing since it's never the iframe case.

I'd expect this member to also be assigned wherever else #navigation-params-sandboxing is set, like https://html.spec.whatwg.org/#populating-a-session-history-entry:navigation-params-sandboxing-2, but in particular, the usual case which is https://html.spec.whatwg.org/#populating-a-session-history-entry:navigation-params-sandboxing-3.

Thanks, fixed.

domfarolino · 2025-12-19T17:01:16Z

source

   </li>

+   <li>
+    <p>If <var>embedder</var> is non-null, then:</p>


So this is solving the pre-existing problem that https://html.spec.whatwg.org/#the-location-interface:concept-location-ancestor-origins-list has, which is that RIGHT when it's created, the relevant document doesn't exist yet, right? Could I ask you to tackle that separately from this PR, just to minimize the moving pieces especially around new document creation.

domfarolino · 2025-12-19T17:04:27Z

source

   <li><p>Set <var>window</var>'s <span data-x="concept-document-window">associated
   <code>Document</code></span> to <var>document</var>.</p></li>

+   <li><p>Set <var>document</var>'s <span


I think we could get rid of this block too, just for now, if we tackle the whole "build up the Location object's ancestor origins stuff after the Document has been created" as a follow-up. I just think that'll simplify this PR up since it's already getting non-trivial.

source

…bidl,dom-core,smaug,jesup,zcorpan This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 UltraBlame original commit: 626bfdb90f3e1a0f78c6a6e832697520396e66bf

…bidl,dom-core,smaug,jesup,zcorpan,devtools-reviewers,nchevobbe This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 gecko-commit: f3415e1670266a11917af7fff4ba14afde5d7ca5 gecko-reviewers: necko-reviewers, webidl, dom-core, smaug, jesup, zcorpan, devtools-reviewers, nchevobbe

…bidl,dom-core,smaug,jesup,zcorpan,devtools-reviewers,nchevobbe This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 UltraBlame original commit: f3415e1670266a11917af7fff4ba14afde5d7ca5

source

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 gecko-commit: da5634c079f9f6ddc76f3ab2b7e2d6c8a91ddb18 gecko-reviewers: necko-reviewers, webidl, dom-core, smaug, jesup, zcorpan

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 gecko-commit: 38f118c0214126f2fa6c33edb0e558656c4ba5b1 gecko-reviewers: necko-reviewers, webidl, dom-core, smaug, jesup, zcorpan

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 gecko-commit: 626bfdb90f3e1a0f78c6a6e832697520396e66bf gecko-reviewers: necko-reviewers, webidl, dom-core, smaug, jesup, zcorpan

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 gecko-commit: f3415e1670266a11917af7fff4ba14afde5d7ca5 gecko-reviewers: necko-reviewers, webidl, dom-core, smaug, jesup, zcorpan, devtools-reviewers, nchevobbe

zcorpan mentioned this pull request Aug 14, 2025

Redact ancestorOrigins using "the document's referrer" #2480

Closed

zcorpan commented Aug 14, 2025

View reviewed changes

source Outdated Show resolved Hide resolved

zcorpan mentioned this pull request Sep 2, 2025

ancestorOrigins web-platform-tests/wpt#5402

Closed

zcorpan changed the title ~~Redact ancestorOrigins using "the document's referrer"~~ Redact ancestorOrigins using referrer policy Sep 3, 2025

annevk reviewed Sep 8, 2025

View reviewed changes

annevk reviewed Sep 10, 2025

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

theIDinside added a commit to theIDinside/firefox that referenced this pull request Sep 10, 2025

Added tentative tests for location.ancestorOrigins

01d7d02

This follows the current revamping of the spec found at whatwg/html#11560 and will change with it, potentially.

zcorpan added the agenda+ To be discussed at a triage meeting label Sep 25, 2025

cwilso mentioned this pull request Oct 3, 2025

Upcoming WHATNOT meeting on 2025-10-02 #11717

Closed

noamr mentioned this pull request Oct 9, 2025

Upcoming WHATNOT meeting on 2025-10-09 #11747

Closed

domfarolino reviewed Oct 23, 2025

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

zcorpan removed the agenda+ To be discussed at a triage meeting label Oct 23, 2025

zcorpan added 2 commits October 27, 2025 22:48

Early return, fix variable casing

0004ccb

zcorpan force-pushed the zcorpan/redact-ancestororigins branch from 3c5e61f to 0004ccb Compare October 27, 2025 21:50

Add two examples

686cd1a

zcorpan mentioned this pull request Dec 18, 2025

Investigate snapshot timing of allow/allowfullscreen attributes #12033

Open

zcorpan commented Dec 19, 2025

View reviewed changes

domfarolino reviewed Dec 19, 2025

View reviewed changes

source Outdated Show resolved Hide resolved

moz-wptsync-bot mentioned this pull request Jan 2, 2026

[Gecko Bug 1085214] Implement location.ancestorOrigins web-platform-tests/wpt#56966

Merged

Also mention origin and origin-when-cross-origin values

b14adac

zcorpan added 2 commits January 9, 2026 14:34

element-or-null

ec93fdd

Remove unneeded note

a7f3489

zcorpan commented Jan 9, 2026

View reviewed changes

source Outdated Show resolved Hide resolved

domfarolino mentioned this pull request Jan 21, 2026

Calculate ancestorOrigins on document creation and store on document #12071

Open

7 tasks

zcorpan added 5 commits January 21, 2026 17:19

Remove parentLocation variable

419e86e

Set navigation-params-iframe-referrer-policy where needed

8eab486

Switch to dl

8503a73

specfmt

a56f772

Export dfns

c0d1ecf

		<li><p>Let <var>innerDoc</var> be <var>location</var>'s <span>relevant
		<code>Document</code></span>.</p></li>

Conversation

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

Uh oh!

Uh oh!

zcorpan commented Aug 14, 2025

Uh oh!

annevk commented Aug 14, 2025

Uh oh!

Uh oh!

zcorpan commented Aug 14, 2025

Example 1

Example 2

Algo

Uh oh!

zcorpan commented Sep 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Algorithm

Polyfill + demo

Examples

iframe referrerpolicy=”no-referrer”

top -> sandboxed iframe -> 3rd party iframe (ad)

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, a.com}

{1, a.com} default referrer policy -> loads {2, a.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, c.com}

{1, a.com} default referrer policy -> loads {2, b.com} with default referrer policy -> loads {3, b.com} with noreferrer attribute on the iframe tag inside {3} -> loads {4, a.com}

Uh oh!

zcorpan commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zcorpan commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Algorithm

Polyfill + demo

Examples

iframe referrerpolicy=”no-referrer”

{1, a.com} default referrer policy -> loads {2, b.com} -> loads {3, a.com}

top -> sandboxed iframe -> 3rd party iframe (ad)

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, a.com}

{1, a.com} default referrer policy -> loads {2, a.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, c.com}

{1, a.com} default referrer policy -> loads {2, b.com} with default referrer policy -> loads {3, b.com} with noreferrer attribute on the iframe tag inside {3} -> loads {4, a.com}

TODOs

Uh oh!

zcorpan commented Sep 8, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

zcorpan commented Oct 8, 2025

Uh oh!

noamr commented Oct 13, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

annevk commented Oct 23, 2025

Uh oh!

zcorpan commented Oct 27, 2025

Uh oh!

johannhof commented Nov 7, 2025

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zcorpan commented Aug 14, 2025 •

edited by pr-preview bot

Loading

zcorpan commented Sep 1, 2025 •

edited

Loading

zcorpan commented Sep 2, 2025 •

edited

Loading

zcorpan commented Sep 5, 2025 •

edited

Loading