Fix Event constructor self-conflict on Hermes#56988
Conversation
|
Hi @mgjohnston! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
Summary:
Removes the
readonly NONE/CAPTURING_PHASE/AT_TARGET/BUBBLING_PHASEdeclarations fromEvent.js.These declarations were intended as type-only annotations, but Babel emits them as runtime class fields, generating constructor assignments such as:
That assignment conflicts with the non-writable
Event.prototype.NONEproperty defined later in the same file viaObject.defineProperty, causing Hermes to throw:This affected
new Event(...)construction and broke APIs relying on Event creation, includingfetch, XHR, andAbortControllerin RN 0.81.x / Expo SDK 54 Hermes environments.The runtime constants themselves are already defined via
Object.definePropertybelow, so removing these declarations preserves the public API and DOM constant semantics while preventing the conflicting class field emission.Related:
Changelog:
[GENERAL] [FIXED] - Prevent Hermes crash when constructing
Eventinstances caused by emitted class fields inEvent.jsTest Plan:
and:
Both previously threw:
After patch:
new Event('foo')succeedsfetch(...)succeedsEvent.NONE === 0Event.CAPTURING_PHASE === 1