Keyboard navigation shortcuts work only in the Priority section of the new activity view
Open 💬 6 comments Opened Aug 5, 2026 by kendonB
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Description
In the new activity view, keyboard navigation shortcuts work only while the selected item is in the Priority section.
The following shortcuts work within Priority but do not work at all in any subsequent section:
Ctrl+Page UpCtrl+Page DownCtrl+1throughCtrl+9
This affects Today, Yesterday, day-specific sections such as Friday, and every other section below Priority.
Steps to reproduce
- Open the new activity view containing items across multiple sections.
- Select an item in Priority and use the shortcuts.
- Confirm that the shortcuts navigate within Priority.
- Select an item in Today, Yesterday, Friday, or another section.
- Try the same shortcuts.
Expected behaviour
The keyboard shortcuts should work throughout the entire activity view and allow navigation both within and between sections.
Actual behaviour
The shortcuts work only in Priority. Once an item outside Priority is selected, the shortcuts do not navigate at all. They also cannot be used to cross from Priority into a later section.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
not a dupe
Still an issue
Still an issue and so easy to fix please
Confirmed still present in Windows build
26.810.7004.0.Read-only inspection of the installed webview bundle shows that, when Activity/Priority data exists,
FWc()constructs the shortcut target list only from the Priority selector (n.flatMap(IWc)). It does not append the rendered Today/Yesterday recent groups. The numbered handler then indexes this shortened list, so slots after the final Priority task are undefined and silently no-op.Shortcut targets should instead be derived from the complete rendered Activity order: Priority, optional Pinned, then Today/Yesterday/recent groups. After de-duplicating thread keys, the existing handler can take the first nine.
This also appears related to #36282, where the numbered shortcuts resolve targets from an ordering that differs from the rendered sidebar order, although that report concerns pinned chats rather than the Activity/Priority boundary.
Still a problem in 26.814.41407