Sign up
View stargazersSign up

[Bug]: J/K do not step the review guide in the chat pull request sidebar#18300

opened29d agobyTtris203

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

  1. Open a chat thread that has a pull request, and open the pull request sidebar beside the chat.
  2. Switch the sidebar to the Guide tab, with a guide that has more than one stop.
  3. Click anywhere on the guide text so focus is in the panel but not on a button.
  4. Press j or k.

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.

  • ChatView registers its keydown handler on window in 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 calls preventDefault() and stopPropagation() (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 body and shouldRedirectInputToComposer has 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 to body.

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 @ f23d0084b6

Environment

Linux

Workaround

Use the up/down arrow buttons beside the hints, or use the standalone pull request screen.

JJulius Marminge29d ago

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 keydown listener on window (ChatView.tsx:8335). When focus is on body, shouldRedirectInputToComposer finds nothing editable or interactive in the event path. So a plain j/k gets inserted into the composer, and the handler calls preventDefault() and stopPropagation() (ChatView.tsx:8044-8053). GuideTour's bubble-phase document listener (GuideTour.tsx:102-114) never sees the key. Even if it did, it returns early on defaultPrevented.

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.

JJulius Marminge29d ago

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, not inert), so the isEditableFocused early return in GuideTour.tsx lets 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 column inert while maximized, and skip the composer refocus while maximized.

JJulius Marminge19d ago

Attempted on Linux with current main 70e5e384da, using the real web dev server and isolated copied state with a linked PR and a stored three-stop guide.

Opening the chat's right panel → Pull request stops at Could not load pull requests: Pull request operation detail failed: GitCafe returned an unreadable response. Retry gives the same result. The linked PR reads successfully through cafe pr view.

The Guide tab could not be reached, so J/K behavior remains unverified. This is a verification-environment blocker; no additional reporter details are requested. Leaving this open for verification with a working PR detail surface.