On Fri, 17 Apr 2026 at 20:59, Olli Pettay <[email protected]> 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 <[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? > > 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. > > > > 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 > > > > > 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/CAPMxTNrfrMbd%3DWtr0JL%3D7v4CfKiUxMRFvxXbm2vD47YJtcCR3w%40mail.gmail.com.
