microsoft / microsoft/fluentui-react-native

MenuList: FocusZone not wired for react-native-windows ('windows'), so menu items are Tab-only (no arrow-key roving focus)

Open Beginner friendly
#4,174 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
1.4k
Forks
179
Avg merge
16h 17m
Merged PRs (30d)
30

Description

Willing to submit a PR to fix?
  • I am willing to submit a PR to fix
Requested priority

Normal

Products/applications affected
Summary

@fluentui-react-native/menu's MenuList only wraps its content in a FocusZone on
macos and win32, not on windows (react-native-windows / Fabric). On windows
the focusZone slot falls back to a plain View, so menu items are reachable only via
Tab — Up/Down/Home/End arrow-key roving focus does not work. This is an accessibility
gap (keyboard + screen-reader users expect arrow-key navigation within a menu).

Location

packages/menu/src/MenuList/MenuList.tsx:

const shouldHaveFocusZone = ['macos', 'win32'].includes(Platform.OS as string);
// ...
slots: { ..., focusZone: shouldHaveFocusZone ? FocusZone : View }

'windows' is not in the list.

Package version(s)

Package manager: yarn @fluentui-react-native/menu: 1.14.35 @fluentui-react-native/focus-zone: 0.21.11 (transitive, via @fluentui-react-native/menu) react-native-windows: 0.74.16 (New Architecture / Fabric, Platform.OS === 'windows') react-native: 0.74.5 react: 18.2.0

OS version(s)

No response

Platform
  • iOS
  • macOS
  • win32
  • windows
  • android
Xcode version

No response

Please provide a reproduction of the bug
Reproduction

Environment: a react-native-windows (New Architecture / Fabric) app,
Platform.OS === 'windows'.

Minimal component:

import { Menu, MenuTrigger, MenuList, MenuItem } from '@fluentui-react-native/menu';
import { Button } from '@fluentui-react-native/button';

export const Repro = () => (
  <Menu>
    <MenuTrigger>
      <Button>Open menu</Button>
    </MenuTrigger>
    <MenuList>
      <MenuItem>Item 1</MenuItem>
      <MenuItem>Item 2</MenuItem>
      <MenuItem>Item 3</MenuItem>
    </MenuList> </Menu>
);

Steps:

1. Run the app on  windows  (RNW / Fabric).
2. Open the menu and move keyboard focus onto the first  MenuItem .
3. Press the Down arrow (also try Up / Home / End).

Expected: focus moves between menu items (Down → Item 2 → Item 3; Up reverses;
Home/End jump to first/last) — the arrow-key roving focus you get on  win32 / macos .

Actual: arrow keys do nothing; items are reachable only by repeatedly pressing Tab.
On  windows ,  MenuList  renders its  focusZone  slot as a plain  View 
( shouldHaveFocusZone = ['macos','win32']  in  packages/menu/src/MenuList/MenuList.tsx ),
so there is no container-level FocusZone to intercept the arrow keys.

Cross-check: the same code on  win32  (or  macos ) navigates correctly with arrows,
confirming the difference is the missing  'windows'  FocusZone wiring, not the menu markup.


### Actual behavior

On  windows ,  focusZone  falls back to  View ; menu items are Tab-only, arrows do nothing.

### Expected behavior

On  windows  (RNW/Fabric),  MenuList  provides container-level arrow-key roving focus
(Up/Down/Home/End), consistent with  win32 / macos .

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in packages/menu/src/MenuList/MenuList.tsx and inspect how shouldHaveFocusZone selects the focusZone slot for each platform. Update the Windows path so MenuList uses the same FocusZone behavior as win32 and macos, then verify that Up, Down, Home, and End move focus between MenuItems on react-native-windows while the existing platforms remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
react-native, typescript
Domain
accessibility, mobile-dev
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.