2034329 - Accessing ancestorOrigins in extension breaks websites (Gmail) that reads ancestorOrigins

Status: VERIFIED FIXED

(WebExtensions :: Untriaged, defect)

Description

[Coxxs]

Attachment: ancestorOrigins-repro-151.zip

Steps to reproduce:

This is a regression:

• Firefox 150.0 (No Bug)
• Firefox Developer 151.0b1 (Broken)
• Firefox Nightly 152.0a1 (Broken)

If a Firefox extension content script reads location.ancestorOrigins,
subsequent reads of location.ancestorOrigins from page script throw
Permission denied.

This causes Gmail to fail to load if any extension accessed location.ancestorOrigins.

Steps

1. Open website/index.html in Firefox.

   • Should show: OK: location.ancestorOrigins.length = 0

2. Load the extension temporarily:

   • Open about:debugging#/runtime/this-firefox.
   • Click Load Temporary Add-on....
   • Select extension/manifest.json.

3. Reload website/index.html.

   • Should now show: Error: Permission denied to access property "length"

4. Open and login to Gmail (optional).

Gmail is broken:

We’re sorry, but your account is temporarily unavailable. We apologize for the inconvenience and suggest trying again in a few minutes. You can view the Google Workspace Status Dashboard for the current status of the service.

Actual results:

Websites unable to access location.ancestorOrigins anymore.

Expected results:

Websites should still be able to access location.ancestorOrigins.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I reproduced the issue as per the STR from Comment 0, on the latest Nightly (152.0a1/20260423082823) and Beta (151.0b1/20260422120759) under Windows 11 and Ubuntu 25.10.
Firefox Release (150.0/20260415192539) is not affected.

The issue occurs exactly as described in Comment 0.
Removing the extension after Gmail fails to work and then reloading the page will restore Gmail functionality.

Performing a mozregression revealed the following:

2026-04-23T11:48:51.754000: DEBUG : Found commit message:
Bug 2016071 - Return cached same-object ancestorOrigins list when possible r=dom-core,smaug

Caches an empty list on Location for when relevant doc is null, and
caches the DOMStringList on Document when the user has called it. Which
moves us closer to spec.

Differential Revision: https://phabricator.services.mozilla.com/D294384

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=af81f8120affd1393e4f37b024cae88a2429fa74&tochange=235c31a3441a5804b35a2d2bef0dc2662620cc4c

Comment 3

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2016071

:sfarre, since you are the author of the regressor, bug 2016071, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Simon Farre [:sfarre]]

I'm guessing that this has to do with the list being created in the wrong realm because content script accessing it first?

Comment 5

[Simon Farre [:sfarre]]

Attachment: Bug 2034329 - Anchor DOMStringList to a specified realm. r=#dom-core,smaug!

DOMStringList::GetParentObject() returned nullptr, so FindAssociatedGlobal in
BindingUtils.h:1845 fell back to JS::CurrentGlobalOrNull(cx), stamping the JS
wrapper into the first caller's compartment. If an extension content script got
there first, subsequent page access required a content→extension CCW, which
security policy blocks, breaking sites like Gmail.

Fix by passing the Document (or inner window) as the DOMStringList parent, so
FindAssociatedGlobal always anchors the wrapper to the content realm — the same
mechanism that makes things like nsContentList immune to this problem.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/90fdec60cd48
https://hg.mozilla.org/integration/autoland/rev/70c4b04955b9
Anchor DOMStringList to a specified realm. r=smaug,dom-core

Comment 7

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

Do we need the fix on beta too?

Comment 8

[Simon Farre [:sfarre]]

Yeah this needs uplift, as bug 2016071 landed in 151.

Comment 9

[Simon Farre [:sfarre]]

Attachment: Bug 2034329 - Anchor DOMStringList to a specified realm.

DOMStringList::GetParentObject() returned nullptr, so FindAssociatedGlobal in
BindingUtils.h:1845 fell back to JS::CurrentGlobalOrNull(cx), stamping the JS
wrapper into the first caller's compartment. If an extension content script got
there first, subsequent page access required a content→extension CCW, which
security policy blocks, breaking sites like Gmail.

Fix by passing the Document (or inner window) as the DOMStringList parent, so
FindAssociatedGlobal always anchors the wrapper to the content realm — the same
mechanism that makes things like nsContentList immune to this problem.

Original Revision: https://phabricator.services.mozilla.com/D296198

Comment 10

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Users extension may prevent location.ancestorOrigins from working, which can cause issues with some websites, like gmail potentially.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Fixes DOMStringList by being able to specify it's parent, so that it can be determined what global's realm it belongs in. Defaults to nullptr, so all other users of DOMStringList shall stay the same. Risk very low.
• String changes made/needed?: No
• Is Android affected?: yes

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/70c4b04955b9

Comment 12

[Coxxs]

Hello! Will this be fixed in version 151? If this bug makes it into the stable release, our extension will have to avoid using ancestorOrigins for the foreseeable future to prevent impacting users. Thanks!

Comment 13

[Simon Farre [:sfarre]]

Hi Coxxs!

This will be uplifted to 151, so these changes will land in 151.

Comment 14

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (152.0a1/20260427155724) under Windows 11 and Ubuntu 25.10.

Following the STR from Comment 0, loading the extension and reloading the website will no longer show the error. Additionally, Gmail can properly load with the extension installed.

Once the fix is uplifted to Beta, I will verify it there as well.

Comment 15

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/505b92907578
https://hg.mozilla.org/releases/mozilla-beta/rev/e1291f95773c

Comment 16

[Alex Cornestean]

Verified as Fixed. Tested on the latest Beta (151.0b4/20260428141554 from https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=e1291f95773c640ccd6109e53bffea36fff79e10) under Windows 11 and Ubuntu 25.10.

Following the STR from Comment 0, loading the extension and reloading the website will no longer show the error. Additionally, Gmail can properly load with the extension installed.