PSA: Node ownerGlobal changes

[Emilio Cobos Álvarez]

Hey,

Once I get bug 1470017 to stick, the `EventTarget.ownerGlobal` property on nodes will change behavior slightly.

This will allow fixing long-standing web components issues (prototypes getting lost on adopt) and some other subtler webcompat issues, like bug 2022763.

In most cases it should be fine to keep using it in the front-end, but there are two subtle behavior changes that might need code to be adjusted:

• If you're dealing with nodes that might have been adopted, `ownerGlobal` might point to the original window of the node, not the one that's currently in.
• .ownerGlobal might also now return non-null a bit more often (after the docshell is gone).

If you need the old behavior, you can use the new `Node.ownerDocGlobal` property. I don't expect much fallout, and I want to proactively change some more code to use `ownerDocGlobal` (e.g. child actors almost always want to look at the window the node is in), but I thought it might be worth a PSA, reach out if you see issues that might be caused by it on the chrome.

Let me know if there are any questions.

Thanks,

 -- Emilio

[Dave Townsend]

Hi Emilio. I'm concerned that this change in behaviour will cause subtle bugs in existing or future code we write. In my mind and I'm sure in the minds of many developers, `ownerGlobal` means the window the element is in and that will be a hard perception to shift. Because it will now mean something different only in rare cases we are likely to use the wrong thing without noticing. Additionally the naming of `ownerGlobal` and `ownerDocGlobal` makes it very unclear that they mean different things.

Since `ownerGlobal` is not part of the web spec can we keep the same behaviour for `ownerGlobal` and introduce a new property for the node's original window?

--
You received this message because you are subscribed to the Google Groups "firef...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firefox-dev...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc-QMRqFPYVyK1v3p67ViNaeLRr1emN%3DaXJRs7jBg%40mail.gmail.com.

[Emilio Cobos Álvarez]

I did think about doing something like that, but it's actually not so
trivial, because `ownerGlobal` is a property on `EventTarget`, even
though we're only changing the behavior of `Node` here.

Also, there are some use cases for `ownerGlobal`, too, I believe. For
example, creating derived objects like events to dispatch generally
should use it:

    node.dispatchEvent(new node.ownerGlobal.CustomEvent(...));

The other issue is that I don't want EventTarget.ownerGlobal to be
subtly different for bindings than in C++ internally, and C++ callers
generally want the new ownerGlobal behavior more often than the old one.

I do understand that for the front-end, having a convenient way
of getting to the global that the node is in (ownerDocGlobal, currently)
is super handy and what 95+% of the code would want, tho...

If the non-Node EventTarget.ownerGlobal usage for bindings is minimal,
wdyt about renaming it from the bindings to something different / more
obviously not-what-you-usually want (or removing it even, perhaps)?

Thanks,

--Emilio

On 4/17/26 2:09 PM, Dave Townsend wrote:
> Hi Emilio. I'm concerned that this change in behaviour will cause subtle
> bugs in existing or future code we write. In my mind and I'm sure in the
> minds of many developers, `ownerGlobal` means the window the element is
> in and that will be a hard perception to shift. Because it will now mean
> something different only in rare cases we are likely to use the wrong
> thing without noticing. Additionally the naming of `ownerGlobal` and
> `ownerDocGlobal` makes it very unclear that they mean different things.
>
> Since `ownerGlobal` is not part of the web spec can we keep the same
> behaviour for `ownerGlobal` and introduce a new property for the node's
> original window?
>

> On Thu, 16 Apr 2026 at 23:22, 'Emilio Cobos Álvarez' via firefox-
> d...@mozilla.org <mailto:firef...@mozilla.org> <firefox-

> d...@mozilla.org <mailto:firef...@mozilla.org>> wrote:
>
> Hey,
>

> Once I get bug 1470017 <https://bugzil.la/1470017> to stick, the

> `EventTarget.ownerGlobal` property on nodes will change behavior
> slightly.
>
> This will allow fixing long-standing web components issues
> (prototypes getting lost on adopt) and some other subtler webcompat

> issues, like bug 2022763 <https://bugzil.la/2022763>.

>
> In most cases it should be fine to keep using it in the front-end,
> but there are two subtle behavior changes that might need code to be
> adjusted:
>

> * If you're dealing with nodes that might have been adopted,

> `ownerGlobal` might point to the original window of the node,
> not the one that's currently in.

> * .ownerGlobal might also now return non-null a bit more often

> (after the docshell is gone).
>
> If you need the old behavior, you can use the new
> `Node.ownerDocGlobal` property. I don't expect much fallout, and I
> want to proactively change some more code to use `ownerDocGlobal`
> (e.g. child actors almost always want to look at the window the node
> is in), but I thought it might be worth a PSA, reach out if you see
> issues that might be caused by it on the chrome.
>
> Let me know if there are any questions.
>
> Thanks,
>  -- Emilio
>
> --
> You received this message because you are subscribed to the Google

> Groups "firef...@mozilla.org <mailto:firef...@mozilla.org>" group.

> To unsubscribe from this group and stop receiving emails from it,
> send an email to firefox-dev...@mozilla.org

> <mailto:firefox-dev...@mozilla.org>.

> To view this discussion visit https://groups.google.com/a/
> mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc-

> QMRqFPYVyK1v3p67ViNaeLRr1emN%3DaXJRs7jBg%40mail.gmail.com <https://
> groups.google.com/a/mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc-
> QMRqFPYVyK1v3p67ViNaeLRr1emN%3DaXJRs7jBg%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
>

[Dave Townsend]

On Fri, 17 Apr 2026 at 14:05, Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

I did think about doing something like that, but it's actually not so
trivial, because `ownerGlobal` is a property on `EventTarget`, even
though we're only changing the behavior of `Node` here.

Do non-node EventTargets already have the new behaviour? I can't think of other EventTargets that can be adopted but I might be missing something.

 

Also, there are some use cases for `ownerGlobal`, too, I believe. For
example, creating derived objects like events to dispatch generally
should use it:

     node.dispatchEvent(new node.ownerGlobal.CustomEvent(...));

I don't fully understand why we would dispatch an event from a different global into the new document, but if that's the case can we add an assert that checks this?

I do understand that for the front-end, having a convenient way
of getting to the global that the node is in (ownerDocGlobal, currently)
is super handy and what 95+% of the code would want, tho...

If the non-Node EventTarget.ownerGlobal usage for bindings is minimal,
wdyt about renaming it from the bindings to something different / more
obviously not-what-you-usually want (or removing it even, perhaps)?

If keeping the existing behaviour of `ownerGlobal` isn't an option then I think we should switch to better named alternatives, perhaps `currentGlobal` and `eventGlobal`.

[Emilio Cobos Álvarez]

On 4/17/26 15:43, Dave Townsend wrote:
> On Fri, 17 Apr 2026 at 14:05, Emilio Cobos Álvarez <emi...@mozilla.com
> <mailto:emi...@mozilla.com>> wrote:
>
> I did think about doing something like that, but it's actually not so
> trivial, because `ownerGlobal` is a property on `EventTarget`, even
> though we're only changing the behavior of `Node` here.
>
>
> Do non-node EventTargets already have the new behaviour? I can't think
> of other EventTargets that can be adopted but I might be missing something.

I mean, that depends on what do you mean with "the new behavior". No
other objects allow otherwise switching prototypes / globals. But yeah
adoption is a node-specific concept (or at least I can't come up with
similar examples off the top of my head).

> Also, there are some use cases for `ownerGlobal`, too, I believe. For
> example, creating derived objects like events to dispatch generally
> should use it:
>
>      node.dispatchEvent(new node.ownerGlobal.CustomEvent(...));
>
>
> I don't fully understand why we would dispatch an event from a different
> global into the new document, but if that's the case can we add an
> assert that checks this?
>
> I do understand that for the front-end, having a convenient way
> of getting to the global that the node is in (ownerDocGlobal,
> currently)
> is super handy and what 95+% of the code would want, tho...
>
> If the non-Node EventTarget.ownerGlobal usage for bindings is minimal,
> wdyt about renaming it from the bindings to something different / more
> obviously not-what-you-usually want (or removing it even, perhaps)?
>
>
> If keeping the existing behaviour of `ownerGlobal` isn't an option then
> I think we should switch to better named alternatives, perhaps
> `currentGlobal` and `eventGlobal`.

I think currentGlobal is a bit unclear on what it is. And the HTML spec
actually defines that term which would make it confusing for platform
engineers IMHO.

ownerDocGlobal is pretty clear if it wasn't for ownerGlobal existing.

WDYT of:

* For now, I land the tweaks in [1].
* I investigate removing ownerGlobal from JS. Basically, push to try
with .ownerGlobal crashing for stuff that isn't a node and audit the
results.
* Based on that we can decide whether to remove stuff or rename the
two accessors.

I'd like Olli's input on the names, as ideally we make C++ match those
names too. The HTML spec has "relevant global" for our current
ownerGlobal[2]. For the ownerDocGlobal that'd be something like "node
document's relevant global" or so.

Would something like relevantGlobal / documentGlobal work for you?

Thanks,

-- Emilio

[1]: https://phabricator.services.mozilla.com/D294805
[2]: https://html.spec.whatwg.org/#relevant

>
>
> Thanks,
>
>   --Emilio
>
> On 4/17/26 2:09 PM, Dave Townsend wrote:
> > Hi Emilio. I'm concerned that this change in behaviour will cause
> subtle
> > bugs in existing or future code we write. In my mind and I'm sure
> in the
> > minds of many developers, `ownerGlobal` means the window the
> element is
> > in and that will be a hard perception to shift. Because it will
> now mean
> > something different only in rare cases we are likely to use the
> wrong
> > thing without noticing. Additionally the naming of `ownerGlobal` and
> > `ownerDocGlobal` makes it very unclear that they mean different
> things.
> >
> > Since `ownerGlobal` is not part of the web spec can we keep the same
> > behaviour for `ownerGlobal` and introduce a new property for the
> node's
> > original window?
> >
> > On Thu, 16 Apr 2026 at 23:22, 'Emilio Cobos Álvarez' via firefox-

> > d...@mozilla.org <mailto:d...@mozilla.org> <mailto:firefox-
> d...@mozilla.org <mailto:firef...@mozilla.org>> <firefox-
> > d...@mozilla.org <mailto:d...@mozilla.org> <mailto:firefox-

> d...@mozilla.org <mailto:firef...@mozilla.org>>> wrote:
> >
> >     Hey,
> >

> >     Once I get bug 1470017 <https://bugzil.la/1470017 <https://

> bugzil.la/1470017>> to stick, the
> >     `EventTarget.ownerGlobal` property on nodes will change behavior
> >     slightly.
> >
> >     This will allow fixing long-standing web components issues
> >     (prototypes getting lost on adopt) and some other subtler
> webcompat

> >     issues, like bug 2022763 <https://bugzil.la/2022763 <https://

> >     Groups "firef...@mozilla.org <mailto:firefox-
> d...@mozilla.org> <mailto:firef...@mozilla.org <mailto:firefox-
> d...@mozilla.org>>" group.

> >     To unsubscribe from this group and stop receiving emails from it,
> >     send an email to firefox-dev...@mozilla.org

> <mailto:firefox-dev%2Bunsu...@mozilla.org>
> >     <mailto:firefox-dev...@mozilla.org <mailto:firefox-
> dev%2Bunsu...@mozilla.org>>.

> >     To view this discussion visit https://groups.google.com/a/

> <https://groups.google.com/a/>
> > mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc- <http://
> mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc->
> >     QMRqFPYVyK1v3p67ViNaeLRr1emN%3DaXJRs7jBg%40mail.gmail.com
> <http://40mail.gmail.com> <https://
> > groups.google.com/a/mozilla.org/d/msgid/firefox-dev/CAFhp-
> qcR_%3Dc- <http://groups.google.com/a/mozilla.org/d/msgid/firefox-
> dev/CAFhp-qcR_%3Dc->
> >     QMRqFPYVyK1v3p67ViNaeLRr1emN%3DaXJRs7jBg%40mail.gmail.com
> <http://40mail.gmail.com>?
> >     utm_medium=email&utm_source=footer>.
> >
>

[Olli Pettay]

On 4/17/26 21:38, Emilio Cobos Álvarez wrote:
> On 4/17/26 15:43, Dave Townsend wrote:
>> On Fri, 17 Apr 2026 at 14:05, Emilio Cobos Álvarez <emi...@mozilla.com <mailto:emi...@mozilla.com>> wrote:
>>
>>     I did think about doing something like that, but it's actually not so
>>     trivial, because `ownerGlobal` is a property on `EventTarget`, even
>>     though we're only changing the behavior of `Node` here.
>>
>>
>> Do non-node EventTargets already have the new behaviour? I can't think of other EventTargets that can be adopted but I might be missing something.
>
> I mean, that depends on what do you mean with "the new behavior". No other objects allow otherwise switching prototypes / globals. But yeah adoption
> is a node-specific concept (or at least I can't come up with similar examples off the top of my head).
>
>>     Also, there are some use cases for `ownerGlobal`, too, I believe. For
>>     example, creating derived objects like events to dispatch generally
>>     should use it:
>>
>>           node.dispatchEvent(new node.ownerGlobal.CustomEvent(...));
>>
>>
>> I don't fully understand why we would dispatch an event from a different global into the new document, but if that's the case can we add an assert
>> that checks this?

Usually it is totally fine to dispatch events from different global. (Some UIEvents may depend on PresContext. Hopefully we aren't creating too many
MouseEvents from JS. Hmm, perhaps we should tweak mPresContext setup in UIEvents to get mPresContext from mTarget)

>>
>>     I do understand that for the front-end, having a convenient way
>>     of getting to the global that the node is in (ownerDocGlobal,
>>     currently)
>>     is super handy and what 95+% of the code would want, tho...
>>
>>     If the non-Node EventTarget.ownerGlobal usage for bindings is minimal,
>>     wdyt about renaming it from the bindings to something different / more
>>     obviously not-what-you-usually want (or removing it even, perhaps)?
>>
>>
>> If keeping the existing behaviour of `ownerGlobal` isn't an option then I think we should switch to better named alternatives, perhaps
>> `currentGlobal` and `eventGlobal`.

I couldn't guess what eventGlobal might mean.

>
> I think currentGlobal is a bit unclear on what it is. And the HTML spec actually defines that term which would make it confusing for platform
> engineers IMHO.
>
> ownerDocGlobal is pretty clear if it wasn't for ownerGlobal existing.
>
> WDYT of:
>
>  * For now, I land the tweaks in [1].
>  * I investigate removing ownerGlobal from JS. Basically, push to try with .ownerGlobal crashing for stuff that isn't a node and audit the results.
>  * Based on that we can decide whether to remove stuff or rename the two accessors.
>

I assume we do need to have ownerGlobal on EventTarget, possibly renamed to relevantGlobal. But perhaps I'm wrong :)

> I'd like Olli's input on the names, as ideally we make C++ match those names too. The HTML spec has "relevant global" for our current ownerGlobal[2].
> For the ownerDocGlobal that'd be something like "node document's relevant global" or so.
>
> Would something like relevantGlobal / documentGlobal work for you?
>

I do like relevantGlobal and documentGlobal.
Not sure they will help too much, since the setup just is confusing when there are multiple globals around. We can't do much about that, since that is
what the web relies on.


-Olli

[Dave Townsend]

On Fri, 17 Apr 2026 at 20:59, Olli Pettay <ope...@mozilla.com> wrote:

On 4/17/26 21:38, Emilio Cobos Álvarez wrote:
> On 4/17/26 15:43, Dave Townsend wrote:
>> On Fri, 17 Apr 2026 at 14:05, Emilio Cobos Álvarez <emi...@mozilla.com <mailto:emi...@mozilla.com>> wrote:
>>
>>     I did think about doing something like that, but it's actually not so
>>     trivial, because `ownerGlobal` is a property on `EventTarget`, even
>>     though we're only changing the behavior of `Node` here.
>>
>>
>> Do non-node EventTargets already have the new behaviour? I can't think of other EventTargets that can be adopted but I might be missing something.
>
> I mean, that depends on what do you mean with "the new behavior". No other objects allow otherwise switching prototypes / globals. But yeah adoption
> is a node-specific concept (or at least I can't come up with similar examples off the top of my head).
>
>>     Also, there are some use cases for `ownerGlobal`, too, I believe. For
>>     example, creating derived objects like events to dispatch generally
>>     should use it:
>>
>>           node.dispatchEvent(new node.ownerGlobal.CustomEvent(...));
>>
>>
>> I don't fully understand why we would dispatch an event from a different global into the new document, but if that's the case can we add an assert
>> that checks this?

Usually it is totally fine to dispatch events from different global. (Some UIEvents may depend on PresContext. Hopefully we aren't creating too many
MouseEvents from JS. Hmm, perhaps we should tweak mPresContext setup in UIEvents to get mPresContext from mTarget)

Why should we do it though?

 

>>
>>     I do understand that for the front-end, having a convenient way
>>     of getting to the global that the node is in (ownerDocGlobal,
>>     currently)
>>     is super handy and what 95+% of the code would want, tho...
>>
>>     If the non-Node EventTarget.ownerGlobal usage for bindings is minimal,
>>     wdyt about renaming it from the bindings to something different / more
>>     obviously not-what-you-usually want (or removing it even, perhaps)?
>>
>>
>> If keeping the existing behaviour of `ownerGlobal` isn't an option then I think we should switch to better named alternatives, perhaps
>> `currentGlobal` and `eventGlobal`.

I couldn't guess what eventGlobal might mean.

This is me not really understanding why we need to use the original global for creating events.

[Emilio Cobos Álvarez]

On 4/17/26 22:37, Dave Townsend wrote:
> Why should we do it though?

In general the event dispatch may not be the best example, but any sort
of "derived" object should generally be created with the relevant global
of the parent object.

Anyways, I looked and there aren't many uses of non-Node ownerGlobal
usage, I think longer term we should try to unexpose that from JS.

But anyways, given the discussion here, for now I filed:

* Bug 2033242 to rename ownerDocGlobal to documentGlobal, and use it
in relevant places.
* Bug 2033243 to rename ownerGlobal to relevantGlobal (both in C++ and
JS).
* Bug 2033191 to remove some of the non-node ownerGlobal usage I've
found (but more to come).

Hopefully that improves a bit the situation? I expect most current usage
of ownerGlobal to go to documentGlobal, long term. We might want to even
lint for .relevantGlobal usage (requiring a comment for why is it the
right thing to do).

But anyways I don't want to snowball it, I think I'd like to get at
least bug 2033242 in this cycle since I'm pretty sure it will fix some
edge cases with child actors.

Thanks,

-- Emilio

> > [1]: https://phabricator.services.mozilla.com/D294805 <https://
> phabricator.services.mozilla.com/D294805>
> > [2]: https://html.spec.whatwg.org/#relevant <https://
> html.spec.whatwg.org/#relevant>

> <mailto:d...@mozilla.org <mailto:d...@mozilla.org>> <mailto:firefox-
> <mailto:firefox->

> >> d...@mozilla.org <mailto:d...@mozilla.org> <mailto:firefox-
> d...@mozilla.org <mailto:firef...@mozilla.org>>> <firefox-
> >>      > d...@mozilla.org <mailto:d...@mozilla.org>

> <mailto:d...@mozilla.org <mailto:d...@mozilla.org>> <mailto:firefox-
> <mailto:firefox->

> >> d...@mozilla.org <mailto:d...@mozilla.org> <mailto:firefox-
> d...@mozilla.org <mailto:firef...@mozilla.org>>>> wrote:
> >>      >
> >>      >     Hey,
> >>      >
> >>      >     Once I get bug 1470017 <https://bugzil.la/1470017

> <https://bugzil.la/1470017> <https://
> >> bugzil.la/1470017 <http://bugzil.la/1470017>>> to stick, the

> >>      >     `EventTarget.ownerGlobal` property on nodes will
> change behavior
> >>      >     slightly.
> >>      >
> >>      >     This will allow fixing long-standing web components
> issues
> >>      >     (prototypes getting lost on adopt) and some other subtler
> >>     webcompat
> >>      >     issues, like bug 2022763 <https://bugzil.la/2022763

> <https://bugzil.la/2022763> <https://
> >> bugzil.la/2022763 <http://bugzil.la/2022763>>>.

> d...@mozilla.org> <mailto:firefox- <mailto:firefox->

> >> d...@mozilla.org <mailto:d...@mozilla.org>> <mailto:firefox-

> d...@mozilla.org <mailto:firef...@mozilla.org> <mailto:firefox-
> <mailto:firefox->
> >> d...@mozilla.org <mailto:d...@mozilla.org>>>" group.

> >>      >     To unsubscribe from this group and stop receiving
> emails from it,
> >>      >     send an email to firefox-dev...@mozilla.org
> <mailto:firefox-dev%2Bunsu...@mozilla.org>

> >>     <mailto:firefox-dev%2Bunsu...@mozilla.org
> <mailto:firefox-dev%252Buns...@mozilla.org>>
> >>      >     <mailto:firefox-dev...@mozilla.org
> <mailto:firefox-dev%2Bunsu...@mozilla.org> <mailto:firefox-
> <mailto:firefox->
> >> dev%2Bunsu...@mozilla.org
> <mailto:dev%252Buns...@mozilla.org>>>.

> >>      >     To view this discussion visit https://
> groups.google.com/a/ <https://groups.google.com/a/>
> >>     <https://groups.google.com/a/ <https://groups.google.com/a/>>
> >>      > mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc- <http://

> mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc-> <http://

> >> mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc- <http://
> mozilla.org/d/msgid/firefox-dev/CAFhp-qcR_%3Dc->>
> >>      >
>  QMRqFPYVyK1v3p67ViNaeLRr1emN%3DaXJRs7jBg%40mail.gmail.com
> <http://40mail.gmail.com>

> >>     <http://40mail.gmail.com <http://40mail.gmail.com>> <https://
> >>      > groups.google.com/a/mozilla.org/d/msgid/firefox-dev/
> CAFhp- <http://groups.google.com/a/mozilla.org/d/msgid/firefox-dev/
> CAFhp->
> >>     qcR_%3Dc- <http://groups.google.com/a/mozilla.org/d/msgid/
> firefox- <http://groups.google.com/a/mozilla.org/d/msgid/firefox->
> >>     dev/CAFhp-qcR_%3Dc->
> >>      >
>  QMRqFPYVyK1v3p67ViNaeLRr1emN%3DaXJRs7jBg%40mail.gmail.com
> <http://40mail.gmail.com>
> >>     <http://40mail.gmail.com <http://40mail.gmail.com>>?
> >>      >     utm_medium=email&utm_source=footer>.
> >>      >
> >>
> >
>

[Dave Townsend]

Sounds good. I don't want to bikeshed too much but I'm not sure `relevantGlobal` really conveys what it is (though maybe that will encourage folks to read the comments!). Perhaps `originalGlobal` is more explanatory?