1085214 - Implement Location.ancestorOrigins

Status: RESOLVED FIXED

(Core :: DOM: Window and Location, enhancement, P3)

Description

[Erik Dubbelboer]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141011015303

Steps to reproduce:

This is a request to implement location.ancestorOrigins like in webkit: https://bugs.webkit.org/show_bug.cgi?id=83493

The number of changes required in webkit were quite small; https://bug-83493-attachments.webkit.org/attachment.cgi?id=136361

This feature is very useful to check which parent domains you are running in and acting on this information.



Expected results:

location.ancestorOrigins should contain a read-only array of hostnames for all the parent frames.

Comment 1

[Josh Matthews [:jdm]]

There's no specification for this yet. It's being tracked at https://www.w3.org/Bugs/Public/show_bug.cgi?id=22699.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is pretty easy to implement if we want to.  The question is whether we want to.  It leaks cross-site information that we may not really want to leak.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, I think we should do this. It seems more important, from a security point of view, to me to enable content to ensure that they are only embedded by those that it expects to be embedded by, than it is to enable content to embed others "anonymously".

But of course this requires a security review.

Comment 4

[Jesse Ruderman]

Pages can already "ensure it's only embedded by those it expects" using CSP or postMessage. Adding an API with confusing privacy implementations doesn't seem necessary to me. I might be okay with this if it were opt-in for each ancestor.

Comment 5

[Tanvi Vyas[:tanvi]]

Such an API could alert a website if they are being iframed by a site they do not expect to be iframed by.  Perhaps they haven't implemented CSP and don't have whitelist of frame-ancestors they should include in the header.  location.ancestorOrigins could help them compile that.

I feel like I'm missing the privacy concern with doing this.  I see that we are leaking information about what websites frame content, but we aren't leaking information about the user.

Needinfo'ing Dan because I'm not sure he's looking at the sec-review queue.

Comment 6

[Erik Dubbelboer]

What is possible with ancestorOrigins is not possible with CSP or postMessage. Also there is nothing confusing about it, it just gives you the domain of every parent all the way up to the origin. It's only the hostname so I don't see how this leaks any privacy related information.

If someone could give me some hints at where to look I could take a shot at implementing this.

Comment 7

[Daniel Veditz [:dveditz]]

There is quite a difference between "Only allow framing from x,y,z" (CSP) and "tell me where else this user goes" (this). There is no other case where we allow a web page to read non-same-origin location data.

What can you do with ancestorOrigins that you can't do with CSP's whitelist approach other than blacklist specific parents? You know how security guys feel about blacklists vs whitelists.

Do you have any example pages that show this feature being used to good effect? Presumably you have examples if you think we need it. According to the webkit bug one use is to work around other non-standard webkit behavior (bug) that wouldn't be an issue in Firefox.

Making more information of this type available is going in the opposite direction of where we're heading with features to control the sending of referrers. Not quite the same, but does make me wonder if we'll then end up having to implement ancestorOrigin-stripping features. There are already people asking about it: http://stackoverflow.com/questions/26046030/change-window-location-ancestororigins

This feature's use is unfortunately not measured (or at least not published) by Chrome:
https://www.chromestatus.com/metrics/feature/popularity

Comment 8

[Erik Dubbelboer]

Dan: our use case is as follows. We offer some embeddable content that for some reasons we don't want embedded in specific websites (domains with a specific category, so a blacklist). We used to use referrers for this. But people found out that if they use an allowed domain in between (so iframe in iframe) they could get around this referrer check. CSP is no use for is in this case. The only way we could detect the real domain our content is embedded in is ancestorOrigin. I'm guessing the stackoverflow question you linked is someone trying to get around this protection.

Comment 9

[zulla]

Attachment: Polishing required; Unnecessary modifications to Link.cpp (Presumably) (This is my first Firefox patch)

Comment 10

[zulla]

Do we actually want location.ancestorOrigins to be DOMStringList?

Comment 11

[Boris Zbarsky [:bzbarsky]]

The Link.cpp changes and URL.cpp changes are definitely not needed.  The attribute should be placed on Location, not on URLUtils.  Also, what's with the nsGlobalWindow.cpp changes?

You shouldn't change nsIDOMLocation at all.

As for the return value... what does Chrome actually do here?  We should either copy that or use a [Cached] sequence<DOMString>.

Comment 12

[zulla]

Won't compile without Link.cpp / URL.cpp support. All other attributes are placed in URLUtils, not Location. nsGlobalWindow.cpp changes to be ignored, will be removed.

 0:13.73 ./URLBinding.cpp:317:9: error: no member named 'GetAncestorOrigins' in 'mozilla::dom::URL'

URLBinding seems to be auto-generated. Difficult to look through it all. WebIDL, *Binding, ...

Chrome is using DOMStringList, but nobody seems to like it.

Comment 13

[zulla]

Patch works, tho.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> Won't compile without Link.cpp / URL.cpp support.

It will if you don't mess with URLUtils.

> All other attributes are placed in URLUtils, not Location.

You mean except the methods on Location?  In any case, you should look at the specs: https://url.spec.whatwg.org/#api and https://html.spec.whatwg.org/multipage/browsers.html#the-location-interface -- which one is the attribute on?  ;)

> URLBinding seems to be auto-generated.

Yes, from the webidl.  Again, don't change URLUtils.

Comment 15

[Erik Dubbelboer]

zulla, great work. Is there any reason why you didn't implement it like a DOMStringList or at least some kind of array with all the parents like it is implemented in webkit?

Comment 16

[zulla]

Attachment: Removed unnecessary changes; Didn't touch URLUtils; Will turn DOMString into Array-ish data structure for multiple iFrames ASAP (Won't use DOMStringList though)

Comment 17

[Erik Dubbelboer]

Any update on this?

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Erik Dubbelboer from comment #8)
> Dan: our use case is as follows. We offer some embeddable content that for
> some reasons we don't want embedded in specific websites (domains with a
> specific category, so a blacklist). We used to use referrers for this. But
> people found out that if they use an allowed domain in between (so iframe in
> iframe) they could get around this referrer check.
Well, ancestorOrigins wouldn't protect from using window.open().
Some 'bad origin' window.opens 'good origin' which embeds the iframe.
'bad origin' communicates with 'good origin' the same way as in iframe case (postMessage).

Comment 20

[Erik Dubbelboer]

(In reply to Olli Pettay [:smaug] from comment #19)
> Well, ancestorOrigins wouldn't protect from using window.open().
> Some 'bad origin' window.opens 'good origin' which embeds the iframe.
> 'bad origin' communicates with 'good origin' the same way as in iframe case
> (postMessage).

This wouldn't really be embedding by the 'bad origin' then, it would be a whole new window from the `good origin` so that's fine by us.

Comment 21

[Brad Hill]

The unfortunate state of the world today is that there's no one cross-browser solution if you want to prevent iframing of your content selectively.  CSP frame-ancestors is implemented by Chrome and Firefox.  XFO ALLOW-FROM is implemented by Edge and Firefox.  ancestorOrigins is implemented by Safari and Chrome.  While I'd love to see Safari and Edge support frame-ancestors, it would be very useful for Firefox to also support ancestorOrigins.  I think the argument that lack of it hasn't stopped any websites from operating can be turned around just as effectively - that it's longstanding presence in Webkit based browsers hasn't led to any privacy disasters, either.

Comment 22

[Erik Dubbelboer]

Is there any update on this since it's now in https://html.spec.whatwg.org/multipage/browsers.html#dom-location-ancestororigins ?

Comment 23

[Boris Zbarsky [:bzbarsky]]

The spec as written constitutes an unnacceptable privacy leak and we have communicated this clearly and repeatedly to the spec editors.  We're not going to implement it in its current form, just like we would not implement a spec that required web sites to be able to read all of a user's locally stored data.

There is a spec issue tracking changing the spec to be acceptable at https://github.com/whatwg/html/issues/1918 and we will implement the resulting spec once that issue is resolved.

Comment 24

[Anne (:annevk)]

FWIW, https://github.com/whatwg/html/pull/2480 has a proposal for a revised specification and https://github.com/web-platform-tests/wpt/pull/5402 has tests. (They are about a year old, might need rebasing. Happy to help if we prioritize this.)

Comment 25

[Chris Peterson [:cpeterson]]

Anne, do we want to implement this?

kmag says this should be easy to implement because we have WebExtension code that implements something similar.

Comment 26

[Anne (:annevk)]

We discussed this feature in the privacy team as it came up at https://github.com/privacycg/storage-partitioning/issues/14 as well. bz's concern about passive trackers is very much alive so we would have to mitigate that if we were to expose this. In particular, if there's no passive way (referrer) for an embedded site to know its parent, this should not reveal the parent to an embedded site.

If we apply that strictly, this would tell you at most about your parent and the only information you would get about further ancestors is how many there are.

This is even further complicated when an embedded site is navigated as the site being navigated to would never know about its parent (other than that one exists).

I'm not sure if that meets the use cases you envision for this feature.

(The HTML Standard PR doesn't account for some of these considerations and would have to be redone, if we were to pursue this further.)

Comment 27

[Thomas Wisniewski [:twisniewski]]

From the webcompat side of things, PG Slots is (accidentally?) treating location.ancestorOrigins as though it exists, but may be zero-length. This seems to just be a coding oversight, as they have fallback code which is just not correctly being falled-back-upon. Thankfully this seems to be a one-off case rather than an obviously-shared code snippet circulating online.

Comment 28

[Dennis Schubert [:denschub]]

WebCompat P3, but we'll bump it higher if we see more critical breakage in the wild.

Comment 29

[cetin]

Really interested in having this feature in Firefox too. Looking forward to it!
I hope P3 means soon : )

Comment 30

[Hsin-Yi Tsai (she/her)[:hsinyi]]

While the standards position is still open, there aren't blocking spec issues. Removing the keyword spec-needed.

Comment 31

[Thomas Wisniewski [:twisniewski]]

I have a work-in-progress patch for this which I will attach to the bug after I've had a moment to rebase it.

I think we'll want to consider whether to really expose all origins. Brave is also considering that: https://github.com/brave/brave-browser/issues/33671

Comment 32

[Simon Pieters [:zcorpan]]

In our triage meeting today I missed Comment 23, which indicates that https://github.com/whatwg/html/issues/1918 is a blocker (and there's a PR at https://github.com/whatwg/html/pull/2480 but it looks like it stalled in 2017 or 2018). (I was going to add back the spec-needed keyword but it was still set.)

Comment 33

[Eli Grey (:sephr)]

Lack of support for location.ancestorOrigins, combined with what I would characterize as an irresponsible feature removal without proper backwards compatibility consideration, has caused the latest Firefox to break Transcend XDI sync, a protocol used for same-site cross-subdomain private (cookie-less) consent sync on websites. The resulting breakage manifests as a connection handshake failure for this postMessage protocol.

The Transcend XDI sync client provides a 'client origin hint' to the Transcend XDI host interface using fragment directives ('xdi-client-origin', 'xdi-channel-id', and 'log'). The xdi-client-origin fragment directive hint is used whenever location.ancestorOrigins is not supported. This implementation has been around for years and is extant across many websites.

Transcend is releasing an update to address this. I am saddened to see a lack of consideration for backwards compatibility in your recent changes which has caused this feature outage.

I implore you to collect usage metrics before making breaking changes to web APIs.

Comment 34

[Eli Grey (:sephr)]

Also, make sure to collect usage metrics using your own browser. Transcend XDI only includes xdi-client-origin in iframe navigations for browsers that don't support location.ancestorOrigins (i.e. Firefox).

Comment 35

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Simon Pieters [:zcorpan] from comment #32)

In our triage meeting today I missed Comment 23, which indicates that https://github.com/whatwg/html/issues/1918 is a blocker (and there's a PR at https://github.com/whatwg/html/pull/2480 but it looks like it stalled in 2017 or 2018). (I was going to add back the spec-needed keyword but it was still set.)

Adding webcompat:blocked according to comment 32.

Comment 36

[Lucy Llewellyn]

I found this by looking over an issue with Windows Admin Center (ref: https://github.com/MicrosoftDocs/Windows-Admin-Center-Ideas-and-Feedback/issues/290) where people have discovered that, in that particular case, it can be worked around by either returning an empty array, or by returning the window.location.origin, to the code that tries to utilise the ancestorOrigin object.

Could we potentially, until the situation with the spec and privacy concerns is resolved, use one of these within Firefox to prevent issues where third-party code tries to use the object but has no fallbacks like the Windows Admin Center?

References for people's attempts to hack the Windows Admin Center's code on each WAC installation showing how we might be able to get some third-party apps and sites running again if we did something similar within Firefox directly:

• https://github.com/MicrosoftDocs/Windows-Admin-Center-Ideas-and-Feedback/issues/290#issuecomment-2599677400
• https://github.com/HerdHeaven/Admin-Scripts/blob/main/Add-FFSupportToWindowsAdminCenter.ps1 (from https://github.com/MicrosoftDocs/Windows-Admin-Center-Ideas-and-Feedback/issues/290#issuecomment-2608238396)

Comment 37

[Carlos]

Returning an empty array could work only for top-level frames as an empty window.location.ancestorOrigins could be used as clue no valid ancestor frames are present for subframes.

Returning an array with one or more window.location.origin would only work if the whole frame subtree is same-origin. Otherwise false information would be given to frames.

In all other scenarios it seems best to keep window.location.ancestorOrigins undefined until an implementation is ready and supported.

Comment 38

[Simon Farre [:sfarre]]

I've got a working example at https://github.com/theIDinside/firefox/tree/location-ancestor-origins-list - and I intend to also add the newer version of the spec that's being worked on by :zcorpan, today. Is it ok if nick this bug?

Comment 39

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Simon Farre [:sfarre] from comment #38)

I've got a working example at https://github.com/theIDinside/firefox/tree/location-ancestor-origins-list - and I intend to also add the newer version of the spec that's being worked on by :zcorpan, today. Is it ok if nick this bug?

Thank you, Simon, for your interest in helping with this. It sounds good to me. :) However, I think it would be worth needinfo-ing Tom, given that he mentioned he had WIPs in comment 31.

Comment 40

[Thomas Wisniewski [:twisniewski]]

Sure, feel free to grab this bug, Simon. Thanks!

Comment 41

[Simon Farre [:sfarre]]

Thank you :hsinyi! And cool :twisniewski!

I have new tests written for the spec in it's current form (found at https://github.com/whatwg/html/pull/11560, which might be subject to minor changes). I do wonder who would/should be the reviewer for the patch?

Comment 42

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Simon Farre [:sfarre] from comment #41)

Thank you :hsinyi! And cool :twisniewski!

I have new tests written for the spec in it's current form (found at https://github.com/whatwg/html/pull/11560, which might be subject to minor changes). I do wonder who would/should be the reviewer for the patch?

If it's new web platform tests, I believe :zcorpan can help.

Comment 43

[Simon Farre [:sfarre]]

Attachment: Bug 1085214 - Implement location.ancestorOrigins r=smaug!

This implements this attribute on Location and also adheres to the
changes to the spec introduced in
https://github.com/whatwg/html/pull/11560

Tentative tests are also added in this patch.

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d93f1bc4f1f1
https://hg.mozilla.org/integration/autoland/rev/da5634c079f9
Implement location.ancestorOrigins r=necko-reviewers,webidl,dom-core,smaug,jesup,zcorpan

Comment 45

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56685 for changes under testing/web-platform/tests

Comment 46

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/cfb40063a45a
https://hg.mozilla.org/integration/autoland/rev/4d1d053e8f79
Revert "Bug 1085214 - Implement location.ancestorOrigins r=necko-reviewers,webidl,dom-core,smaug,jesup,zcorpan" for causing failures at location-ancestor-origins.sub.html.

Comment 47

[Atila Butkovits]

Backed out for causing failures at location-ancestor-origins.sub.html.

Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/4d1d053e8f79a60d298e3a77e790cfbb2036deb0

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=Zgrd4h3lRiOn-ekgEorUBQ.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=da5634c079f9f6ddc76f3ab2b7e2d6c8a91ddb18

Failure log: https://treeherder.mozilla.org/logviewer?job_id=539564689&repo=autoland&task=Zgrd4h3lRiOn-ekgEorUBQ.0&lineNumber=2626

Comment 48

[Simon Farre [:sfarre]]

Added ini file to wpt test to enable pref so that the test run with the feature turned on & requested landing for that.

Comment 49

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ec3055a6d507
https://hg.mozilla.org/integration/autoland/rev/38f118c02141
Implement location.ancestorOrigins r=necko-reviewers,webidl,dom-core,smaug,jesup,zcorpan

Comment 50

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d8eb790ee4bb
https://hg.mozilla.org/integration/autoland/rev/18b3759cd423
Revert "Bug 1085214 - Implement location.ancestorOrigins r=necko-reviewers,webidl,dom-core,smaug,jesup,zcorpan" for causing wpt failures @ location-ancestor-origins.sub.html

Comment 51

[amarc]

Backed out for causing wpt failures

• Backout link
• Push with failures
• Failure Log

Comment 52

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 53

[Simon Farre [:sfarre]]

I've identified & addressed the issue causing the backout. Submitted new try runs for that and will request new landing if all green.

Comment 54

[Simon Farre [:sfarre]]

Latest try run: https://treeherder.mozilla.org/jobs?repo=try&revision=5879fab8659d56e6466769ea86c1903c5dc36e6a

Comment 55

[Simon Farre [:sfarre]]

Latest try run pushed here: https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=169300 - will land when green.

After discussion on matrix, we will enable this in nightly by default.

Comment 56

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7f88f484011c
https://hg.mozilla.org/integration/autoland/rev/626bfdb90f3e
Implement location.ancestorOrigins r=necko-reviewers,webidl,dom-core,smaug,jesup,zcorpan

Comment 57

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56805 for changes under testing/web-platform/tests

Comment 58

[amarc]

https://hg.mozilla.org/mozilla-central/rev/626bfdb90f3e

Comment 59

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 60

[Donal Meehan [:dmeehan]]

:sfarre, could you consider nominating this for a release note? (Process info)

Comment 61

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/accc77502ee5
https://hg.mozilla.org/integration/autoland/rev/79fc433e7198
Revert "Bug 1085214 - Implement location.ancestorOrigins r=necko-reviewers,webidl,dom-core,smaug,jesup,zcorpan" for causing dt failures @browser_dbg-expressions-error.js.

Comment 62

[agoloman]

Backed out for causing dt failures @browser_dbg-expressions-error.js. It was hidded by Bug 2006557 until now.

• Backout link
• Push with failures
• Failure Log

Comment 63

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56863 for changes under testing/web-platform/tests

Comment 64

[Simon Farre [:sfarre]]

(In reply to agoloman from comment #62)

Backed out for causing dt failures @browser_dbg-expressions-error.js. It was hidded by Bug 2006557 until now.

• Backout link
• Push with failures
• Failure Log

Trying to find where it uses location.ancestorOrigins. Is it expecting a result that we now provide differently or what?

Comment 65

[Daniel Holbert [:dholbert]]

(In reply to Simon Farre [:sfarre] from comment #64)

Trying to find where it uses location.ancestorOrigins. Is it expecting a result that we now provide differently or what?

I was similarly a bit confused about the connection, so I checked in with sheriffs to be sure the backout wasn't a mistake... But it looks like the backout did indeed make the test go from failing to passing.

Push before backout:
https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&searchStr=linux%2C24.04%2Cdebug%2Cmochitests%2Cwith%2Chttp3%2Cserver%2Ctest-linux2404-64%2Fdebug-mochitest-devtools-chrome-http3%2Cdt&revision=0c56dd09060daf98d508498c19c0c012948db1b2
The test browser_dbg-expressions-error.js runs in dt13 and fails:
https://treeherder.mozilla.org/logviewer?job_id=540716004&repo=autoland&task=M53lLjg3Qqu3YdAkPBagCQ.0&lineNumber=7575

The backout push:
https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&searchStr=linux%2C24.04%2Cdebug%2Cmochitests%2Cwith%2Chttp3%2Cserver%2Ctest-linux2404-64%2Fdebug-mochitest-devtools-chrome-http3%2Cdt&revision=79fc433e7198a1493c08115f0ef8f5d40fe8fce8
The test browser_dbg-expressions-error.js runs in dt11 and passes:
https://treeherder.mozilla.org/logviewer?job_id=540719863&repo=autoland&task=a4E3QR5lQsGcIDPkOEhagA.0
https://treeherder.mozilla.org/logviewer?job_id=540716957&repo=autoland&task=b1QpeQQJQM-ZyddQDUkRxg.0

Comment 66

[Simon Farre [:sfarre]]

At first review this does not seem to be an error on this patch behalf, but on the test itself, what is the path forward in such a scenario?

Ancestor origins is not used by the failing test: https://searchfox.org/firefox-main/source/devtools/client/debugger/test/mochitest/browser_dbg-expressions-error.js#22

I will look into it further but its surprising if location.ancestorOrigins is the problem and not the test itself.

Comment 67

[Simon Farre [:sfarre]]

Yeah it's difficult to tell what the test actually is testing because it's just magic numbers and no explanation.

I will need-info the people who has worked on it. :nchevobbe you seem to have touched the test, can you explain what's going on? Is this just a matter of bumping the expected number from 37 to 39?

Comment 68

[Emilio Cobos Álvarez [:emilio]]

The addExpression stuff uses the location object and most likely gathers own properties for autocomplete or display in the debugger. So it is fairly likely that it changed the expectation of that test fwiw.

Comment 69

[Simon Farre [:sfarre]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #68)

The addExpression stuff uses the location object and most likely gathers own properties for autocomplete or display in the debugger. So it is fairly likely that it changed the expectation of that test fwiw.

Seems likely, right. One for the property of the DOM string list, and one for the getter, would account for the difference of 2. Thanks!

Comment 70

[Cristian Tuns]

The backout merged to central: https://hg.mozilla.org/mozilla-central/rev/79fc433e7198

Comment 71

[Nicolas Chevobbe [:nchevobbe]]

Attachment: CleanShot 2025-12-19 at 07.57.47.png

(In reply to Simon Farre [:sfarre] from comment #67)

Yeah it's difficult to tell what the test actually is testing because it's just magic numbers and no explanation.

I will need-info the people who has worked on it. :nchevobbe you seem to have touched the test, can you explain what's going on? Is this just a matter of bumping the expected number from 37 to 39?

The test adds a location watch expression in the debugger and expands it so we have all its properties displayed.
You patch adds ancestorOrigins and we also show the getter node (see screenshot). So yes, we have 2 additional properties now, and we should bump the number from 37 to 39
The same goes for the two failing assertions in devtools/client/debugger/test/mochitest/browser_dbg-expressions.js

Comment 72

[Simon Farre [:sfarre]]

The test adds a location watch expression in the debugger and expands it so we have all its properties displayed.
You patch adds ancestorOrigins and we also show the getter node (see screenshot). So yes, we have 2 additional properties now, and we should bump the number from 37 to 39
The same goes for the two failing assertions in devtools/client/debugger/test/mochitest/browser_dbg-expressions.js

Thanks a bunch!

Addressed failing tests & latest/last update to spec.
Try run: https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=170036

Comment 73

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 74

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b4ac69ad6835
https://hg.mozilla.org/integration/autoland/rev/f3415e167026
Implement location.ancestorOrigins r=necko-reviewers,webidl,dom-core,smaug,jesup,zcorpan,devtools-reviewers,nchevobbe

Comment 75

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56966 for changes under testing/web-platform/tests

Comment 76

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/f3415e167026

Comment 77

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 78

[Donal Meehan [:dmeehan]]

:sfarre, could you consider nominating this for a release note? (Process info)

Comment 79

[Simon Farre [:sfarre]]

Why is this notable:

Adds support for location.ancestorOrigins attribute, with support for the redacted ancestor origins spec that's being finalized.

Affects Firefox for Android:

Support of the attribute is intended for all platforms.

Links:

The current work in progress implementation of the spec that :zcorpan is working on can be found here.

Previous spec iteration of Location.ancestorOrigins is described here

Comment 80

[Donal Meehan [:dmeehan]]

Thanks, added to the Fx148 nightly release notes, please allow 30 minutes for the site to update.
Keeping the relnote-firefox flag as ? to keep it on the radar for inclusion in the final Fx148 release notes.

Comment 81

[Chris Mills [:cmills]]

The feature is already documented on MDN; I've added a rel note in https://github.com/mdn/content/pull/42826. I think we can therefore consider this one complete in terms of MDN docs requirements.

Comment 82

[Donal Meehan [:dmeehan]]

Added to the final Fx148 release notes