You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Return and Space keys do not trigger onPress events #1622
Go to System Settings and enable Keyboard Navigation:
In RNTester, go to the Pressable page
Press the Tab key to move the focus ring to a Presable
Press Return key or Space bar
Expected Behavior
Pressing Return or Space should trigger the press of the Pressable
Actual Behavior
The system Beep chimes and no press event is triggered
Reproducible Demo
No response
Additional context
This is a regression starting in .68.
.68 introduced the validKeysDown prop. It seems like Touchable and Pressable should have "enter" and "space" on by default.
However, I think the better long term thing to do is deprecate our 'validKeysDown' prop in favor of 'keyDownEvents', the prop used in React Native Windows for a few reasons:
In React Native Windows, all keyboard events are sent to JS. 'keyDownEvents' just specifies which keyboard events should have their native behavior suppressed. This is more flexible to JS developers than our 'validKeysDown' prop where only the events we specify are sent to This difference isn't obvious and leads to bugs like the one here.
The same prop and behavior makes it easier to write cross platform code. I've had a lot of bugs trying to write cross platform keyboard handlers in FluentUI React Native.
I have another draft PR out to switch us to the new prop: #1615
Both PRs are on my backlog, and I wasn't any to merge either soon. If this issue is blocking, I can prioritize the first one perhaps.
Its nearly the same as your except instead of fixing the "validKeys" collection in the JS, I fixed it in the native RCTView.m code as I was having trouble fixing all the Pressability components -- Pressable just worked, but the various Touchables did not. I'll test your branch. One problem I see in your branch tho: you test for 'Enter'" and 'Space', but on macOS the spacebar event is actually ' '. Perhaps another thing that should be fixed for consistency with Windows.
It is a priority for us as its an accessibility regression since .68
Activity
[-]Describe the problem[/-][+]Return and Space keys do not trigger onPress events[/+]Saadnajmi commentedon Jan 6, 2023
I actually have a draft PR out for this: #1614
However, I think the better long term thing to do is deprecate our 'validKeysDown' prop in favor of 'keyDownEvents', the prop used in React Native Windows for a few reasons:
In React Native Windows, all keyboard events are sent to JS. 'keyDownEvents' just specifies which keyboard events should have their native behavior suppressed. This is more flexible to JS developers than our 'validKeysDown' prop where only the events we specify are sent to This difference isn't obvious and leads to bugs like the one here.
keyDownEvents is better documented, and the prop that is in the actual apex: https://github.com/microsoft/react-native-windows/blob/main/vnext/proposals/active/keyboard-reconcile-desktop.md
The same prop and behavior makes it easier to write cross platform code. I've had a lot of bugs trying to write cross platform keyboard handlers in FluentUI React Native.
I have another draft PR out to switch us to the new prop: #1615
Both PRs are on my backlog, and I wasn't any to merge either soon. If this issue is blocking, I can prioritize the first one perhaps.
tom-un commentedon Jan 6, 2023
Oh, great! I also made a draft PR with a fix here: https://github.com/microsoft/react-native-macos/pull/1623/files.
Its nearly the same as your except instead of fixing the "validKeys" collection in the JS, I fixed it in the native RCTView.m code as I was having trouble fixing all the Pressability components -- Pressable just worked, but the various Touchables did not. I'll test your branch. One problem I see in your branch tho: you test for
'Enter'" and'Space', but on macOS the spacebar event is actually' '. Perhaps another thing that should be fixed for consistency with Windows.It is a priority for us as its an accessibility regression since .68
github-actions commentedon Jul 6, 2023
This issue 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.