fix(player): keep a keyboard Enter out of focus navigation
Pressing Enter over the player put the whole app into keyboard mode and dropped focus onto Play/Pause, even with Video Player Navigation off. Two independent paths did it. InputModeTracker promoted on any key satisfying isNavigationKey, a set that unioned activation, dismissal and the menu key with the arrows and consulted no setting at all; separately the surface's Select handler always asked the chrome for focus. Escape had the same effect, which on desktop reads as the mouse cursor vanishing mid-playback. Both now ask one predicate. eventRequestsFocusNavigation decides whether the app switches to keyboard mode and whether a key may hand focus to the chrome, so the two cannot disagree and focus can never land on a control while focus chrome is still suppressed. Activation and dismissal act on what already has focus, so they answer no; Tab, the menu key, a remote's OK or BACK, and an arrow that will really traverse answer yes. The one input the predicate cannot read off the event, whether the focused feature owns arrow keys, rides on the node as DirectionalShortcutFocusNode instead of on a subtree, so every sheet, prompt and OSD button stays an ordinary traversal target with nothing to re-enable. playerDirectionalNavigationEnabled and videoPlayerNavigationPreference replace five hand-copied pref-or-isTV expressions and a screen-level cache that disagreed with the live getter after a toggle. Services whose input is synthesized past HardwareKeyboard announce themselves through InputModeTracker.reportNonPointerInput rather than two static callbacks and three copies of a highlight-strategy write. That registration is now identity-guarded: the bootstrap-to-app tree swap disposed the outgoing tracker after the incoming one initialised and cleared both callbacks, so gamepad and companion remote input had stopped switching to keyboard mode entirely. Falling out of the same rule: a companion heartbeat no longer flips an idle desktop host into keyboard mode, analog-stick drift promotes only past the deadzone that actually navigates, Enter keeps toggling playback once the chrome is up, Tab both reaches and traverses the OSD, and the player surface claims the remote from mount rather than only when the chrome starts hidden, so the first key on a desktop route is a playback shortcut instead of the screen node's chrome-raising self-heal. isNavigationKey becomes isReservedControlKey, since its real meaning is a shell key rather than a text character and the old name is what invited the conflation. The unreachable PlayerChromeFocusTarget.timeline goes with it.
This commit is contained in:
@@ -4,9 +4,8 @@ import 'package:flutter/material.dart';
|
||||
import 'package:flutter/services.dart';
|
||||
|
||||
import '../utils/platform_detector.dart';
|
||||
import '../services/gamepad_service.dart';
|
||||
import 'dpad_navigator.dart';
|
||||
import '../services/companion_remote/companion_remote_receiver.dart';
|
||||
import 'focus_navigation_intent.dart';
|
||||
|
||||
/// Tracks whether the user is navigating via keyboard/d-pad or pointer (mouse/touch).
|
||||
///
|
||||
@@ -55,6 +54,21 @@ class InputModeTracker extends StatefulWidget {
|
||||
return Platform.isAndroid && isKeyboardMode(context);
|
||||
}
|
||||
|
||||
/// Report input from a device that cannot point — gamepad, companion remote,
|
||||
/// Siri Remote touch. Those services synthesize their key events through
|
||||
/// [KeyEventSimulatorController], which dispatches straight down the focus
|
||||
/// chain and never reaches [HardwareKeyboard], so they cannot be observed by
|
||||
/// [eventRequestsFocusNavigation] and must announce themselves here.
|
||||
///
|
||||
/// Calls `setState`, so never call this during build. A no-op when no tracker
|
||||
/// is mounted.
|
||||
static void reportNonPointerInput() {
|
||||
final state = _instance;
|
||||
if (state != null && state.mounted) state._setMode(InputMode.keyboard);
|
||||
}
|
||||
|
||||
static _InputModeTrackerState? _instance;
|
||||
|
||||
@override
|
||||
State<InputModeTracker> createState() => _InputModeTrackerState();
|
||||
}
|
||||
@@ -66,23 +80,21 @@ class _InputModeTrackerState extends State<InputModeTracker> {
|
||||
@override
|
||||
void initState() {
|
||||
super.initState();
|
||||
// Published before anything can report input. The outgoing tracker of a
|
||||
// subtree swap disposes *after* the incoming one initialises, so teardown
|
||||
// is identity-guarded — otherwise startup's bootstrap→app swap would leave
|
||||
// the live registration cleared.
|
||||
InputModeTracker._instance = this;
|
||||
// Initialize focus highlight strategy based on starting mode
|
||||
_updateFocusHighlightStrategy(_mode);
|
||||
// Listen to hardware keyboard events globally
|
||||
HardwareKeyboard.instance.addHandler(_handleKeyEvent);
|
||||
|
||||
// Register callback for gamepad input to switch to keyboard mode
|
||||
GamepadService.onGamepadInput = () => _setMode(InputMode.keyboard);
|
||||
|
||||
// Register callback for companion remote input to switch to keyboard mode
|
||||
CompanionRemoteReceiver.onRemoteInput = () => _setMode(InputMode.keyboard);
|
||||
}
|
||||
|
||||
@override
|
||||
void dispose() {
|
||||
HardwareKeyboard.instance.removeHandler(_handleKeyEvent);
|
||||
GamepadService.onGamepadInput = null;
|
||||
CompanionRemoteReceiver.onRemoteInput = null;
|
||||
if (identical(InputModeTracker._instance, this)) InputModeTracker._instance = null;
|
||||
super.dispose();
|
||||
}
|
||||
|
||||
@@ -91,9 +103,10 @@ class _InputModeTrackerState extends State<InputModeTracker> {
|
||||
// events after route pops (see BackKeySuppressorObserver).
|
||||
BackKeyPressTracker.handleKeyEvent(event);
|
||||
|
||||
// Only switch to keyboard mode on navigation key down (not repeats, releases,
|
||||
// or non-navigation keys like volume buttons or letter keys while typing)
|
||||
if (event is KeyDownEvent && event.logicalKey.isNavigationKey) {
|
||||
// Only a key that asks to navigate by focus starts a keyboard session.
|
||||
// Activation and dismissal act on what is already focused, so promoting on
|
||||
// them would arm focus chrome for a viewer who never asked to navigate.
|
||||
if (eventRequestsFocusNavigation(event)) {
|
||||
_setMode(InputMode.keyboard);
|
||||
}
|
||||
// Return false to let the event continue propagating
|
||||
|
||||
Reference in New Issue
Block a user