Repository navigation
Force native EventTarget event dispatching on for the React renderer - #59911
Merged
rubennorte merged 3 commits intoNov 10, 2026
Merged
Conversation
## Summary: react#59896 removed `enableNativeEventTargetEventDispatching` from `ReactNativeFeatureFlags`, but the vendored Fabric renderer still reads it through `react-native/react-private-interface` to choose between `dispatchNativeEvent` and the legacy plugin-based dispatch. With the getter gone, the renderer saw `undefined`, treated the flag as off, and fell back to the legacy path, so listeners registered with `addEventListener` were never called. The `ReactNativeFeatureFlags` getter in the private interface now returns the real flags plus `enableNativeEventTargetEventDispatching: () => true`, so only the renderer sees it. This can be removed once the renderer is synced from a React build that no longer reads the flag. ## Changelog: [Internal] ## Test Plan: - `yarn fantom packages/react-native/src/private/renderer/core/__tests__/EventTargetDispatching-itest.js`: 16 failures before, 78 passed / 20 skipped after. - `yarn fantom packages/react-native/src/private/webapis/dom packages/react-native/src/private/renderer`: 513 passed, 26 skipped. - `yarn eslint --max-warnings 0` and `yarn prettier --check` on both changed files pass. - `yarn flow-check` reports only 2 unrelated parse errors from local git ref logs under `.git/logs/refs/remotes/` whose names end in `.json`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
meta-cla
Bot
added
the
CLA Signed
Contributor
|
Wouldn't this force all the properties to materialize? Why not add it back to the react feature flags config with default true? |
Member
Author
They'd be materialized anyway, but it's only the accessor functions, not the underlying flag read. |
Summary: react#59896 made `ReactNativeElement` unconditionally extend `EventTarget`, which imports the `AbortSignal` type, pulling `AbortSignal.d.ts` into the generated types checked by `yarn test-generated-typescript`. The internal `abortSignal(reason = ..., signal)` helper declares a defaulted parameter before a required one, which flow-api-translator emits as `abortSignal(reason?: unknown | void, signal: AbortSignal)` and tsc rejects with TS1016. Reorder the parameters to `abortSignal(signal, reason = ...)` and update both internal callers. The public API snapshot is unchanged. Changelog: [Internal] Test Plan: - `yarn build-types --skip-snapshot && yarn test-generated-typescript`: fails with TS1016 before, passes after - `yarn build-types --validate`: API snapshot is up to date - `yarn eslint --max-warnings 0 packages/react-native/src/private/webapis/dom/abort-api/`
javache
approved these changes
Nov 10, 2026
rubennorte
changed the title
rubennorte
changed the title
## Summary: react#59797 added `experimental_onSafeAreaInsetsChange` to the root `logbox_inspector` view, and react#59893 refreshed the LogBox snapshots without that change, so both landed but the committed `LogBoxInspector` baseline is missing the prop. The two inspector snapshot tests fail in Fantom CI mode, which no longer rewrites mismatched baselines (react#59895). Regenerate the two affected snapshots; the only change is the added prop on the root view. ## Changelog: [Internal] ## Test Plan: - `CI=true yarn fantom packages/react-native/Libraries/LogBox`: 2 snapshot failures before; 90/90 tests and 54/54 snapshots pass after, on two consecutive runs. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
#59896 removed
enableNativeEventTargetEventDispatchingfromReactNativeFeatureFlags, but the vendored Fabric renderer still reads it throughreact-native/react-private-interfaceto choose betweendispatchNativeEventand the legacy plugin-based dispatch. With the getter gone, the renderer sawundefined, treated the flag as off, and fell back to the legacy path, so listeners registered withaddEventListenerwere never called.The
ReactNativeFeatureFlagsgetter in the private interface now returns the real flags plusenableNativeEventTargetEventDispatching: () => true, so only the renderer sees it. This can be removed once the renderer is synced from a React build that no longer reads the flag.UPDATE: Also fixes 2 other breakages (outdated Fantom snapshot and generated TS types)
Changelog:
[Internal]
Test Plan:
yarn fantom packages/react-native/src/private/renderer/core/__tests__/EventTargetDispatching-itest.js: 16 failures before, 78 passed / 20 skipped after.yarn fantom packages/react-native/src/private/webapis/dom packages/react-native/src/private/renderer: 513 passed, 26 skipped.yarn eslint --max-warnings 0andyarn prettier --checkon both changed files pass.yarn flow-checkreports only 2 unrelated parse errors from local git ref logs under.git/logs/refs/remotes/whose names end in.json.