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-
[email protected] <mailto:[email protected]> <firefox-
[email protected] <mailto:[email protected]>> 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 "[email protected] <mailto:[email protected]>" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
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>.
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/bbd620e6-27c3-439a-938e-bde55f4f1fd8%40mozilla.com.
