[$250] Pressing Esc closes fullscreen video instead of 3 dot menu

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.78-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #89424
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11, Chrome
App Component: Chat Report View

Action Performed:

Precondition:

• The user has attached a video in a chat

1.Go to https://staging.new.expensify.com/
2. Open the chat with the attached video
3. Click the expand icon at the top right corner of the video thumbnail to open the video in fullscreen mode
4. Click the 3 dot menu in the video player
5. Click Playback speed to keep the menu open
6. Press the Esc key

Expected Result:

When the 3 dot menu is opened in fullscreen mode, pressing the Esc key should close only the menu without exiting the fullscreen video.

Actual Result:

When the video is in fullscreen mode and the 3 dot menu is opened, pressing the Esc key closes the fullscreen video instead of closing only the 3 dot menu.

(outside fullscreen mode, the Esc key works correctly and closes only the menu, indicating the fullscreen video shortcut is overriding the menu shortcut)

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7158403_1779238868571.TPSFcjrbZt.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7158403

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056917311920149815
• Upwork Job ID: 2056917311920149815
• Last Price Increase: 2026-05-20
• Automatic offers:
• linhvovan29546 | Contributor | 111486234

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/c1022b9e81bc4946ac152815766a74dfc4d12be66f516dc5593a00b9620d66d5

[MelvinBot]

Proposal

What is the root cause of that problem?

The browser's Fullscreen API has built-in Escape key handling that cannot be intercepted or prevented by JavaScript. When requestFullscreen() is active on the <video> element, the browser exits fullscreen on Escape at a lower level before any JS event handlers fire.

The event sequence when Escape is pressed with the popover open in fullscreen:

1. Browser level (unpreventable): Browser detects Escape during fullscreen, internally calls document.exitFullscreen() and fires the fullscreenchange event
2. expo-video layer: The fullscreenchange listener triggers onFullscreenExit, which unconditionally sets isFullScreenRef.current = false
3. JS level: The keyup event fires and ReanimatedModal's capture handler closes the popover

So both fullscreen exits and the popover closes, but the user only wanted the popover to close.

What changes do you think we should make in order to solve the problem?

In BaseVideoPlayer.tsx:572, modify the onFullscreenExit callback to check isPopoverVisible (already available in scope). If the popover is open when fullscreen exits, immediately re-enter fullscreen via videoViewRef.current?.enterFullscreen().

The popover's existing Escape handler (ReanimatedModal) will still close the popover normally. The net result: popover closes, video stays fullscreen.

What alternative solutions did you explore? (Optional)

1. Keyboard Lock API (navigator.keyboard.lock(['Escape'])) — would prevent the browser from handling Escape natively in fullscreen, but has limited browser support (Chrome/Edge only, not Firefox/Safari).
2. Render the popover inside the fullscreen container instead of as a Modal portal — would avoid the conflict entirely but requires significant architectural changes to the popover rendering in fullscreen mode.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a video is playing in fullscreen mode and the user opens the 3-dot context menu, pressing Escape closes the fullscreen video entirely instead of only closing the context menu. Outside of fullscreen the Escape key correctly closes only the menu.

What is the root cause of that problem?

There are two competing Escape key handlers. The PopoverProvider registers a keyup listener on document (capture phase, true) that calls e.stopImmediatePropagation() after closing a popover, which should prevent other handlers from seeing the event. The problem is that browsers implement the fullscreen Escape key exit as a native browser behavior that fires on keydown, not on keyup. Because the browser's native fullscreen-exit logic runs on keydown — before any keyup event is dispatched — calling stopImmediatePropagation on the later keyup event has no effect on the already-executed browser behavior. Outside of fullscreen, there is no native browser shortcut intercepting keydown, so the keyup-based stopImmediatePropagation in PopoverProvider is sufficient to suppress other JS handlers and appears to work correctly.

App/src/components/PopoverProvider/index.tsx

Lines 92 to 105 in 29ad1e2

	useEffect(() => {
	const listener = (e: KeyboardEvent) => {
	if (e.key !== 'Escape') {
	return;
	}
	if (closePopover()) {
	e.stopImmediatePropagation();
	}
	};
	document.addEventListener('keyup', listener, true);
	return () => {
	document.removeEventListener('keyup', listener, true);
	};
	}, [closePopover]);

What changes do you think we should make in order to solve the problem?

The fix belongs in src/components/PopoverProvider/index.tsx. The existing keyup listener that closes the popover on Escape already calls e.stopImmediatePropagation(), which handles the JS-layer event propagation correctly. The missing piece is suppressing the browser's native fullscreen exit, which is triggered on keydown. We should add a second event listener on document that listens to keydown in the capture phase and, when a popover is currently open and the key is Escape, calls e.preventDefault() on that keydown event. preventDefault() on the keydown Escape event is what tells the browser not to perform its built-in fullscreen-exit action. The keyup listener already handles closing the popover and calling stopImmediatePropagation to prevent other JS handlers from also reacting. The new keydown listener only needs to check whether a popover is active (via activePopoverRef.current) and, if so, call e.preventDefault() to cancel the browser's native fullscreen exit — leaving the actual popover-close logic to the existing keyup handler.

App/src/components/PopoverProvider/index.tsx

Lines 92 to 105 in 29ad1e2

	useEffect(() => {
	const listener = (e: KeyboardEvent) => {
	if (e.key !== 'Escape') {
	return;
	}
	if (closePopover()) {
	e.stopImmediatePropagation();
	}
	};
	document.addEventListener('keyup', listener, true);
	return () => {
	document.removeEventListener('keyup', listener, true);
	};
	}, [closePopover]);

What alternative solutions did you explore? (Optional)

N/A

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-20 05:13:33 UTC.

Proposal

What is the root cause of that problem?

The "fullscreen" here is the AttachmentModalScreen lightbox (a JS <Modal>), opened by the expand icon — not the browser's native Fullscreen API. The video 3‑dot menu is a PopoverMenu, which on web is itself a <Modal>. When Esc is pressed with the menu open, the lightbox is dismissed by two independent Escape handlers, neither of which checks whether the lightbox is the topmost modal:

1. Keydown path. AttachmentModalBaseContent subscribes Escape via useKeyboardShortcut(..., {shouldBubble: true}), which react-native-key-command fires on a document keydown capture listener:

App/src/pages/media/AttachmentModalScreen/AttachmentModalBaseContent/index.tsx

Line 180 in e8c6aa8

useKeyboardShortcut(CONST.KEYBOARD_SHORTCUTS.ESCAPE, () => onClose?.(), {shouldBubble: true});

onClose() dismisses the lightbox, and because it bubbles, the global handler also runs Navigation.dismissModal():

App/src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/EscapeHandler.tsx

Lines 48 to 90 in e8c6aa8

	useEffect(() => {
	const shortcutConfig = CONST.KEYBOARD_SHORTCUTS.ESCAPE;
	const unsubscribeEscapeKey = KeyboardShortcut.subscribe(
	shortcutConfig.shortcutKey,
	() => {
	if (modal?.willAlertModalBecomeVisible) {
	return;
	}
	if (modal?.disableDismissOnEscape) {
	return;
	}
	if (shouldRenderSecondaryOverlayForWideRHP) {
	Navigation.closeRHPFlow();
	return;
	}
	if (shouldRenderSecondaryOverlayForRHPOnSuperWideRHP) {
	Navigation.dismissToSuperWideRHP();
	return;
	}
	if (shouldRenderSecondaryOverlayForRHPOnWideRHP || shouldRenderTertiaryOverlay) {
	Navigation.dismissToPreviousRHP();
	return;
	}
	const topmostRootRoute = navigationRef.getRootState()?.routes.at(-1);
	const isFocusedOnWorkspaceTab =
	topmostRootRoute?.name === NAVIGATORS.TAB_NAVIGATOR && getActiveTabName(topmostRootRoute as NavigationRoute) === NAVIGATORS.WORKSPACE_NAVIGATOR;
	if (isFocusedOnWorkspaceTab) {
	handleEscapeKeyInWorkspaceNavigator();
	return;
	}
	Navigation.dismissModal();
	},
	shortcutConfig.descriptionKey,
	shortcutConfig.modifiers,
	true,
	true,
	);

PopoverMenu only claims ENTER/SPACE — never ESCAPE — so nothing higher in the shortcut stack stops it:

App/src/components/PopoverMenu.tsx

Lines 511 to 536 in e8c6aa8

	useKeyboardShortcut(
	CONST.KEYBOARD_SHORTCUTS.ENTER,
	() => {
	if (focusedIndex === -1) {
	return;
	}
	selectItem(focusedIndex);
	setFocusedIndex(-1); // Reset the focusedIndex on selecting any menu
	},
	{isActive: isVisible},
	);
	const keyboardShortcutSpaceCallback = useCallback(
	(e?: GestureResponderEvent | KeyboardEvent) => {
	if (shouldUseScrollView) {
	return;
	}
	e?.preventDefault();
	},
	[shouldUseScrollView],
	);
	// On web, pressing the space bar after interacting with the parent view
	// can cause the parent view to scroll when the space bar is pressed.
	useKeyboardShortcut(CONST.KEYBOARD_SHORTCUTS.SPACE, keyboardShortcutSpaceCallback, {isActive: isWeb && isVisible, shouldPreventDefault: false});

2. Keyup path. The lightbox's <Modal> renders ReanimatedModal, whose handleEscape (a document.body keyup capture listener) calls onBackButtonPressHandler(), which returns true for any visible modal — there is no topmost guard:

App/src/components/Modal/ReanimatedModal/index.tsx

Lines 78 to 102 in e8c6aa8

	const handleEscape = useCallback(
	(e: KeyboardEvent) => {
	if (e.key !== 'Escape' || onBackButtonPressHandler() !== true) {
	return;
	}
	e.stopImmediatePropagation();
	},
	[onBackButtonPressHandler],
	);
	useEffect(() => {
	if (getPlatform() === CONST.PLATFORM.WEB) {
	document.body.addEventListener('keyup', handleEscape, {capture: true});
	} else {
	backHandlerListener.current = BackHandler.addEventListener('hardwareBackPress', onBackButtonPressHandler);
	}
	return () => {
	if (getPlatform() === CONST.PLATFORM.WEB) {
	document.body.removeEventListener('keyup', handleEscape, {capture: true});
	} else {
	backHandlerListener.current?.remove();
	}
	};
	}, [handleEscape, onBackButtonPressHandler]);

Since the lightbox's Modal mounts before the popover's, its document.body capture listener is registered first and wins the firing order, then calls stopImmediatePropagation() — so the popover's own keyup-close never runs, and the lightbox closes.

Outside the lightbox there is no second modal, so the popover's own ReanimatedModal keyup closes only the menu — which is exactly why it behaves correctly there.

Notably, the app already tracks modal stacking: BaseModal registers every modal in the closeModals stack (BaseModal.tsx#L146, Modal.ts#L5), last = topmost. Both Escape handlers ignore it and dismiss the lightbox even though the popover is the topmost modal.

What changes do you think we should make in order to solve the problem?

One scoped change per Escape path.

1. Keydown — let the popover claim Escape so the lightbox's useKeyboardShortcut and EscapeHandler never run. New subscriptions splice in at index 0, so the popover (mounted last) runs first; shouldBubble: false stops the stack. In PopoverMenu (alongside the existing ENTER handler):

+    useKeyboardShortcut(
+        CONST.KEYBOARD_SHORTCUTS.ESCAPE,
+        () => {
+            setCurrentMenuItems(menuItems);
+            setEnteredSubMenuIndexes(CONST.EMPTY_ARRAY);
+            onClose();
+        },
+        {isActive: isVisible, shouldBubble: false},
+    );

2. Keyup — make ReanimatedModal honor Escape only when it's the topmost modal. This is the actual defect: a background modal dismisses itself on Escape. Gate handleEscape so a non-topmost instance ignores the key:

     const handleEscape = useCallback(
         (e: KeyboardEvent) => {
-            if (e.key !== 'Escape' || onBackButtonPressHandler() !== true) {
+            if (e.key !== 'Escape' || !isTopmostModal() || onBackButtonPressHandler() !== true) {
                 return;
             }
             e.stopImmediatePropagation();
         },
         [onBackButtonPressHandler],
     );

isTopmostModal() compares this instance against a small module-level stack of mounted ReanimatedModal escape handlers — push a per‑instance token on mount, pop it on cleanup, inside the existing web keyup effect (L88–L102). With the lightbox no longer topmost, only the popover's keyup runs and just the menu closes.

Both paths together: the popover closes on keydown (change 1), and on the trailing keyup the lightbox is skipped because it isn't topmost (change 2).

On the submenu (the repro keeps "Playback speed" open), this closes the whole menu — matching the issue's Expected Result. If design instead prefers Esc to step back one submenu level, change 1 can reuse the existing back-button branch (PopoverMenu.tsx#L401-L430) when enteredSubMenuIndexes.length > 0.

What alternative solutions did you explore? (Optional)

1. Suppressing the lightbox's keyup with a one-shot document keyup listener added on each Escape press inside the popover. It works, but it patches the symptom per‑keystroke with a transient global listener and leaves the keyup leak in place for every other nested‑modal case; gating ReanimatedModal on topmost fixes the class once.
2. Re-entering fullscreen / re-opening the menu after the lightbox starts closing — causes a visible flash, and is also based on the incorrect assumption that this is the native browser Fullscreen API rather than a JS modal.
3. Reading the video's isPopoverVisible up in AttachmentModalBaseContent to skip its Escape — requires prop-drilling popover state out of BaseVideoPlayer; the topmost-modal check already encodes "something is open above me" generically.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-20 02:09:30 UTC.

Proposal

What is the root cause of that problem?

When the video is opened in fullscreen (the AttachmentModalScreen lightbox) and the 3‑dot menu is open, both UIs subscribe to Escape and the AttachmentModal's subscriber fires first, so Esc dismisses the whole lightbox instead of just the menu.

AttachmentModalBaseContent subscribes Escape → onClose() here:

App/src/pages/media/AttachmentModalScreen/AttachmentModalBaseContent/index.tsx

Lines 179 to 180 in e3b5200

	// Close the modal when the escape key is pressed
	useKeyboardShortcut(CONST.KEYBOARD_SHORTCUTS.ESCAPE, () => onClose?.(), {shouldBubble: true});

And the global navigator‑level Esc subscriber also calls Navigation.dismissModal():

App/src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/EscapeHandler.tsx

Lines 48 to 92 in e3b5200

	useEffect(() => {
	const shortcutConfig = CONST.KEYBOARD_SHORTCUTS.ESCAPE;
	const unsubscribeEscapeKey = KeyboardShortcut.subscribe(
	shortcutConfig.shortcutKey,
	() => {
	if (modal?.willAlertModalBecomeVisible) {
	return;
	}
	if (modal?.disableDismissOnEscape) {
	return;
	}
	if (shouldRenderSecondaryOverlayForWideRHP) {
	Navigation.closeRHPFlow();
	return;
	}
	if (shouldRenderSecondaryOverlayForRHPOnSuperWideRHP) {
	Navigation.dismissToSuperWideRHP();
	return;
	}
	if (shouldRenderSecondaryOverlayForRHPOnWideRHP || shouldRenderTertiaryOverlay) {
	Navigation.dismissToPreviousRHP();
	return;
	}
	const topmostRootRoute = navigationRef.getRootState()?.routes.at(-1);
	const isFocusedOnWorkspaceTab =
	topmostRootRoute?.name === NAVIGATORS.TAB_NAVIGATOR && getActiveTabName(topmostRootRoute as NavigationRoute) === NAVIGATORS.WORKSPACE_NAVIGATOR;
	if (isFocusedOnWorkspaceTab) {
	handleEscapeKeyInWorkspaceNavigator();
	return;
	}
	Navigation.dismissModal();
	},
	shortcutConfig.descriptionKey,
	shortcutConfig.modifiers,
	true,
	true,
	);
	return () => unsubscribeEscapeKey();

The VideoPopoverMenu is just a PopoverMenu, and PopoverMenu doesn't currently claim Escape at all — it relies on its underlying Modal's keyup‑capture Esc handler:

App/src/components/Modal/ReanimatedModal/index.tsx

Lines 78 to 102 in e3b5200

	const handleEscape = useCallback(
	(e: KeyboardEvent) => {
	if (e.key !== 'Escape' || onBackButtonPressHandler() !== true) {
	return;
	}
	e.stopImmediatePropagation();
	},
	[onBackButtonPressHandler],
	);
	useEffect(() => {
	if (getPlatform() === CONST.PLATFORM.WEB) {
	document.body.addEventListener('keyup', handleEscape, {capture: true});
	} else {
	backHandlerListener.current = BackHandler.addEventListener('hardwareBackPress', onBackButtonPressHandler);
	}
	return () => {
	if (getPlatform() === CONST.PLATFORM.WEB) {
	document.body.removeEventListener('keyup', handleEscape, {capture: true});
	} else {
	backHandlerListener.current?.remove();
	}
	};
	}, [handleEscape, onBackButtonPressHandler]);

So when Esc is pressed with the menu open:

1. keydown → react-native-key-command's document listener (registered at module init with {capture: true} — see node_modules/react-native-key-command/src/KeyCommand/index.js:200‑202) walks the shortcut stack. AttachmentModalBaseContent's ESCAPE callback runs and calls onClose() → AttachmentModal starts dismissing.
2. keyup → ReanimatedModal's document.body Esc handler fires (in registration order) and calls onBackButtonPress on the AttachmentModal's Modal — same result.

The popover's own Modal would have handled keyup too, but the AttachmentModal's Modal is registered earlier in the DOM listener order, so it wins.

What changes do you think we should make in order to solve the problem?

I'd have PopoverMenu claim Escape while it's visible, so the surrounding modal stack never sees it.

The stack-based fix is to subscribe via useKeyboardShortcut with shouldBubble: false. New subscriptions splice in at index 0, so the popover's handler runs first; without bubbling, nothing else in the ESCAPE stack runs:

+    // Claim Escape while the menu is open so surrounding modal subscribers (AttachmentModal's
+    // onClose, EscapeHandler's Navigation.dismissModal) don't fire. `shouldBubble: false`
+    // stops the shortcut stack after this handler. Also swallow the matching keyup so Modal's
+    // keyup-Escape handler (on document.body) doesn't close the parent modal either — we
+    // register the suppressor on `document` so it fires before any document.body capture listener.
+    const handleEscape = useCallback(() => {
+        const escapeKey = CONST.KEYBOARD_SHORTCUTS.ESCAPE.shortcutKey;
+        const suppressKeyUp = (upEvent: KeyboardEvent) => {
+            if (upEvent.key === escapeKey) {
+                upEvent.stopImmediatePropagation();
+            }
+            document.removeEventListener('keyup', suppressKeyUp, true);
+        };
+        document.addEventListener('keyup', suppressKeyUp, true);
+        onClose();
+    }, [onClose]);
+    useKeyboardShortcut(CONST.KEYBOARD_SHORTCUTS.ESCAPE, handleEscape, {isActive: isVisible, shouldBubble: false});

The one‑shot capture-phase keyup listener on document (not document.body) is needed because ReanimatedModal's Esc handler runs on keyup, not keydown — without it, the surrounding Modal would still close on the same keystroke. Listeners on document fire before any capture listener on document.body, so it reliably wins.

NOTE: Cross‑platform & memory safety: the keyup suppressor lives in a platform helper (suppressNextEscapeKeyUp/index.ts web, index.native.ts no‑op), so PopoverMenu.tsx has no DOM access. Its cleanup function is stored in a ref and invoked on unmount, so the listener can't leak if the component unmounts before the matching keyup arrives.

What alternative solutions did you explore?

1. Plain document.addEventListener('keydown', …, { capture: true }) inside the popover. Doesn't work: react-native-key-command registers its capture-phase document listener at module init, before any React useEffect, and capture listeners on the same element fire in registration order — so the shortcut stack still walks first and the AttachmentModal closes before my handler runs.
2. Auto-exit the lightbox/fullscreen when the menu opens and re-enter on close. Avoids the listener-priority problem but creates a jarring visual flash each time the menu opens — bad UX.
3. Make the AttachmentModal's Esc subscriber skip when a child popover is visible. Requires either prop‑drilling popover state up to the modal or a new global "is popover open" flag — both more invasive than letting the popover own its own Esc.

Demo:

REC-20260520070750.mp4

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ahmedGaber93 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022056917311920149815