Repository navigation
[Bug]: J/K do not step the review guide in the chat pull request sidebar #18300
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Open a chat thread that has a pull request, and open the pull request sidebar beside the chat.
- Switch the sidebar to the Guide tab, with a guide that has more than one stop.
- Click anywhere on the guide text so focus is in the panel but not on a button.
- Press
jork.
Expected behavior
j moves to the next stop and k to the previous one, as the J K hints beside the stop arrows indicate. This is what happens on the standalone pull request screen.
Actual behavior
The stop does not change. Focus jumps to the chat composer and the letter is typed into it.
Cause
The chat's type-to-focus handler takes the key before the guide tour sees it.
-
ChatViewregisters itskeydownhandler onwindowin the capture phase (apps/web/src/components/ChatView.tsx:8335). For any plain single character typed outside an editable or interactive element, it inserts the key into the composer and callspreventDefault()andstopPropagation()(ChatView.tsx:8044-8053). -
The guide tour's J/K handler is a bubble-phase listener on
document(apps/web/src/components/pullRequest/guide/GuideTour.tsx:102-114), so it never receives the event. -
Clicking guide text focuses nothing, so the event target is
bodyandshouldRedirectInputToComposerhas no way to tell the key was meant for the panel. -
Clicking a stop button first does not help either. The arrow buttons, and at sidebar width the stop list, render inside
GuideStop, which is keyed by position (GuideTour.tsx,key={position}), so stepping remounts them and focus falls back tobody.
The standalone pull request screen has no chat composer, which is why the keys work there.
Impact
Minor bug or occasional failure
Version or commit
main @ f23d008
Environment
Linux
Workaround
Use the up/down arrow buttons beside the hints, or use the standalone pull request screen.
Activity
juliusmarminge commentedon Oct 11, 2026
Note
Grok responding on behalf of Julius.
Confirmed on main (4bd0ecc). This is a bug. ChatView registers its type-to-focus handler as a capture-phase
keydownlistener onwindow(ChatView.tsx:8335). When focus is onbody,shouldRedirectInputToComposerfinds nothing editable or interactive in the event path. So a plainj/kgets inserted into the composer, and the handler callspreventDefault()andstopPropagation()(ChatView.tsx:8044-8053). GuideTour's bubble-phasedocumentlistener (GuideTour.tsx:102-114) never sees the key. Even if it did, it returns early ondefaultPrevented.Open PR #18132 only changes right-panel launcher letters, so it doesn't fix this.
One possible fix: when the event path or the focused element is inside the right panel, or while the guide tour is active, the type-to-focus handler could skip the key.
Workaround for now: use the stop arrow buttons, or click a rail stop first so a button has focus.
juliusmarminge commentedon Oct 12, 2026
Note
Grok responding on behalf of Julius.
Related case folded in from #18600: when the PR panel is maximized, the chat composer keeps focus (the column is only collapsed to
w-0, notinert), so theisEditableFocusedearly return inGuideTour.tsxlets J/K type into the hidden composer. The window-focus refocus effect can also put focus back there. #18338 does not cover this yet; a full fix should blur the composer or make the chat columninertwhile maximized, and skip the composer refocus while maximized.