On 4/17/26 15:43, Dave Townsend wrote:
On Fri, 17 Apr 2026 at 14:05, Emilio Cobos Álvarez <[email protected]
<mailto:[email protected]>> 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-
> [email protected] <mailto:[email protected]> <mailto:firefox-
[email protected] <mailto:[email protected]>> <firefox-
> [email protected] <mailto:[email protected]> <mailto:firefox-
[email protected] <mailto:[email protected]>>> 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://
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:firefox-
[email protected]> <mailto:[email protected] <mailto:firefox-
[email protected]>>" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to [email protected]
<mailto:firefox-dev%[email protected]>
> <mailto:[email protected] <mailto:firefox-
dev%[email protected]>>.
> 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>.
>
--
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/269e5149-547e-4317-9549-921241d582e3%40mozilla.com.
