Bug: Tab does not accept the highlighted @ mention suggestion in collaborative chat

[paullizer]

Issue

In multi-user (collaborative) conversations, the @ mention autocomplete menu in the chat composer does not accept the highlighted suggestion when the user presses Tab. Tab instead falls through to the browser default and moves focus out of the message box, so the partially typed @name text is left behind.

Most users expect Tab to complete an autocomplete entry. This is also inconsistent with the agent-instruction mention menu elsewhere in the app (static/js/agent_instruction_mentions.js), which already treats Tab and Enter the same way.

Steps to Reproduce

1. Open a shared / collaborative conversation on /chats.
2. Click into the message box and type @.
3. The participant / agent suggestion menu (#collaboration-mention-menu) opens with the first entry highlighted.
4. Optionally type a few characters of a name, or use the arrow keys to move the highlight.
5. Press Tab.

Expected Behavior

Tab accepts the highlighted suggestion exactly like Enter does today, inserting the mention into the composer and keeping focus in the message box.

Actual Behavior

Tab does nothing to the menu. Focus moves to the next control in the page, the mention menu closes on blur, and the raw @par text remains in the composer. Only Enter accepts a suggestion.

Impact

Minor UX friction for every user of shared conversations. There is a workaround (press Enter), so this is not blocking, but it breaks a very common typing habit and makes the composer feel inconsistent with the rest of the app.

Notes

Suspected area:

• application/single_app/static/js/chat/chat-collaboration.js — handleComposerKeydown() handles ArrowDown, ArrowUp, Enter, and Escape, but has no Tab branch.
• application/single_app/static/js/chat/chat-messages.js — the #user-input keydown listener delegates to window.chatCollaboration.handleComposerKeydown(e) and returns early when it returns true.
• application/single_app/static/js/agent_instruction_mentions.js — reference implementation that already handles case 'Tab': case 'Enter': together.

Agreed behavior:

• Plain Tab accepts the highlighted suggestion (participant tag, agent/model ai_tag, or the invite-confirmation flow, matching Enter).
• Shift+Tab is left alone so normal focus-backwards behavior still works.
• Tab in the "No matching participants..." empty state also falls through to normal focus movement.

Related accessibility gap found in the same code: #collaboration-mention-menu is declared role="listbox" in templates/chats.html, but the suggestion items rendered by renderMentionMenu() are plain buttons with no role="option" / aria-selected, so assistive tech cannot announce which suggestion is highlighted during keyboard navigation. This will be fixed alongside the Tab support.

Related but not duplicates — both concern which suggestions appear rather than keyboard selection:

• Bug: scope collaborative @ suggestions to active Models or Agents mode #935 — scope collaborative @ suggestions to active Models or Agents mode
• Bug: define and test multi-agent @ mention behavior #936 — define and test multi-agent @ mention behavior

[paullizer]

Fix is up in #1301.

What changed — handleComposerKeydown() in application/single_app/static/js/chat/chat-collaboration.js now handles Tab. The inline Enter selection body was extracted into a shared selectActiveMentionSuggestion() helper so both keys route through one implementation of the participant tag, ai_tag invocation target, and invite-confirmation branches. A hasActiveMentionSuggestion() guard runs before preventDefault(), so Tab is only captured when there is something to accept.

As agreed on the issue, Shift+Tab and the "No matching participants..." empty state are left unhandled and keep normal focus movement, and the Enter guard is unchanged.

The listbox accessibility gap noted in the issue was fixed in the same pass: suggestions are now real options with stable ids and aria-selected, and the composer references the highlighted option via aria-activedescendant paired with aria-controls and aria-autocomplete="list". The aria-controls pairing is required because ARIA 1.2 only resolves aria-activedescendant from a focused textbox when the option lives inside the controlled element, and #collaboration-mention-menu is a sibling of #user-input rather than a descendant. Those attributes are applied only while the menu is open. The highlighted option is also scrolled into view inside the height-capped menu.

Validation — measured by running the real shipped functions against a jsdom document, with the pre-fix source pulled from git show HEAD:

Observation	Before	After
Mention menu handles Tab	false	true
Tab prevents default focus movement	No	Yes
Suggestions inserted on Tab	0	1
Suggestions inserted on Enter	1	1 (unchanged)
Suggestions exposed with role="option"	0	1 per suggestion
aria-activedescendant on the composer	absent	tracks the highlighted option

• functional_tests/test_collaboration_mention_tab_autocomplete.py — 5/5 passed, and fails 3/5 against the pre-fix source, so it is a real regression test rather than a tautology.
• ui_tests/test_chat_collaboration_mention_tab_selection.py — new Playwright regression test covering Tab, ArrowDown+Tab, Enter, Shift+Tab, focus retention, and the listbox ARIA.
• 54/54 passed across the existing collaboration and chat functional tests that read chat-collaboration.js, so no regressions.

Shipped in version 0.260.004, with a fix doc at docs/explanation/fixes/COLLABORATION_MENTION_TAB_AUTOCOMPLETE_FIX.md and a release notes entry.

Follow-ups / not in scope here

• Bug: scope collaborative @ suggestions to active Models or Agents mode #935 and Bug: define and test multi-agent @ mention behavior #936 still stand — they cover which suggestions appear, which this change does not touch.
• Unrelated pre-existing bug spotted during review: ui_tests/test_workspace_document_selection_controls.py:46 calls .first() instead of the .first property, so that test errors out before its assertions run. Left alone deliberately; worth its own issue.