[taibin]

Summary:

Fix Android Modal's handling of the ESCAPE key so that JavaScript is reliably notified (via onRequestClose) instead of the dialog dismissing itself before JS sees the event.

Problem

ReactModalHostView installs an OnKeyListener that only reacts on ACTION_UP for KEYCODE_BACK / KEYCODE_ESCAPE, calling handleCloseAction() to let JS decide whether to close.

However, Android's Dialog.onKeyDown() handles these two keys asymmetrically:

• KEYCODE_BACK — ACTION_DOWN only calls event.startTracking(); the dialog is dismissed on ACTION_UP via onBackPressed(). Our ACTION_UP interception works fine.
• KEYCODE_ESCAPE — ACTION_DOWN directly calls Dialog.cancel(). By the time our ACTION_UP handler would run, the dialog is already being dismissed, so onRequestClose is never delivered to JS.

Net effect: pressing ESCAPE on Android closes the Modal unconditionally, bypassing JS (breaks apps that rely on onRequestClose for confirmation dialogs, unsaved-changes prompts, etc.).

Fix

Restructure the key listener to branch on keyCode first:

• For KEYCODE_BACK / KEYCODE_ESCAPE:
  • Consume ACTION_DOWN (return true) to prevent Dialog.onKeyDown() from dismissing the dialog.
  • On ACTION_UP, call handleCloseAction() as before, giving JS the final say.
• For all other keys, preserve the previous behavior of forwarding ACTION_UP to the current Activity (needed by the dev menu, etc.).

Test Plan:

• Render a <Modal visible> on Android, attach onRequestClose handler, press the hardware BACK button — handler fires, modal stays open unless JS sets visible={false}. (Regression coverage: unchanged behavior.)
• Same setup, press ESCAPE on a connected keyboard / emulator — handler now fires correctly; previously the modal closed without JS notification.
• Open the dev menu shortcut while a modal is not showing — still works (non-BACK/ESCAPE keys still forwarded to Activity).

Changelog:

[ANDROID] [FIXED] - Modal's onRequestClose is now correctly invoked when pressing ESCAPE on Android (previously the dialog was dismissed before JS was notified).

[github-actions]

Warning

JavaScript API change detected

This PR commits an update to ReactNativeApi.d.ts, indicating a change to React Native's public JavaScript API.

• Please include a clear changelog message.
• This change will be subject to additional review.

This change was flagged as: POTENTIALLY_BREAKING

[react-native-bot]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[miniware9]

Confirmed on React Native 0.88.0 (New Architecture, Expo SDK 58), Android 17 emulator, debug build: with a <Modal transparent animationType="fade" onRequestClose={…}> open, adb shell input keyevent KEYCODE_ESCAPE dismisses the dialog without calling onRequestClose, so visible stays true and no press on the screen does anything afterwards (#56411). KEYCODE_BACK calls onRequestClose as expected. While the modal is up, the focused window is the dialog's own, so the key does reach it.

The cause is the one this PR describes: Dialog.onKeyDown (Android 9 and later) calls cancel() for KEYCODE_ESCAPE on ACTION_DOWN when the dialog is cancelable, which it is by default, and the listener on main acts only on ACTION_UP, after the dialog is gone. Consuming ACTION_DOWN, as this PR does, addresses exactly that.

For comparison, #56631 forwards only ESCAPE's ACTION_UP and, as its own test asserts, lets ACTION_DOWN through to super.dispatchKeyEvent, which reaches Dialog.onKeyDown and cancels the dialog first. As far as I can read it, it would not change the behavior on a device.