Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What realm should be used for creating events from "fire an event" #352

Closed
domenic opened this issue Oct 26, 2016 · 1 comment
Closed

What realm should be used for creating events from "fire an event" #352

domenic opened this issue Oct 26, 2016 · 1 comment

Comments

@domenic
Copy link
Member

domenic commented Oct 26, 2016

Continuation of a discussion that started in #349. /cc @bzbarsky @Ms2ger.

A test at http://w3c-test.org/submissions/4088/html/semantics/forms/resetting-a-form/reset-form-event-realm.html reveals the following, assuming that reset()'s "fire an event" is representative in general:

  • Chrome and Safari use the target's relevant Realm Further testing reveals this to be false; see Test that events are created in the relevant realm of their target web-platform-tests/wpt#4088.
  • Firefox may use the target's relevant Realm; however, since it does the currently-nonstandard-but-oft-debated thing where adopting an element changes its relevant Realm, it's not interoperable with Chrome/Safari
  • Edge coincidentally matches Firefox, but not for the same reasons. That is, it uses frames[1]'s realm in that test, but it does not have Gecko's adoption semantics, at least as far as I can tell by testing the prototypes (they were not swizzled). . Maybe it is going by the realm of the target's document?

I think maybe we should standardize on using target's relevant Realm, and then the fact that Gecko is not interoperable just ends up being part of the larger issue where Gecko has different adoption semantics. Thoughts welcome.

@bzbarsky
Copy link

Firefox may use the target's relevant Realm

It does. Specifically, in Firefox construction of an event requires passing in an EventTarget. The Realm used for the event is then whatever the Realm of the EventTarget is at the point when the event's script representation is first created. In practice, I think the observable effect is that the Realm is whatever the Realm of the target is at the point when the event itself is created, but in theory if you have a C++ listener for the event that does something that triggers page script and the page script changes the target's Realm before any JS listeners for the event end up running, the event JS reflection could be created later than the event itself and after the target has changed Realms.

at least as far as I can tell by testing the prototypes (they were not swizzled)

One could actually change the Realm of the underlying object without swizzling the prototypes (e.g. to maintain an invariant that the Realm and hence origin of all nodes in a node tree is the same). This would only be observable through APIs that use relevant Realm directly.... We could just ask Microsoft what Edge is really doing.

Maybe it is going by the realm of the target's document?

What happens for targets that aren't nodes?

I think maybe we should standardize on using target's relevant Realm

That seems perfectly acceptable to me, since it matches Gecko's behavior anyway, more or less. ;)

domenic added a commit to whatwg/html that referenced this issue Oct 27, 2016
Closes #1959. All other MessageEvents are created as part of "fire an
event", which is covered by whatwg/dom#352.
domenic added a commit to whatwg/html that referenced this issue Oct 27, 2016
Closes #1959. All other MessageEvents are created as part of "fire an
event", which is covered by whatwg/dom#352.
zcorpan pushed a commit to whatwg/html that referenced this issue Nov 1, 2016
Closes #1959. All other MessageEvents are created as part of "fire an
event", which is covered by whatwg/dom#352.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
Closes whatwg#1959. All other MessageEvents are created as part of "fire an
event", which is covered by whatwg/dom#352.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants