Global search: Cmd/Ctrl-click and right-click to open results without losing the query

Objective

• Let staff open one or more search hits (inspections, quotes, contacts) from the navbar global search in a way that matches familiar browser patterns: ⌘+click / Ctrl+click and right-click → Open in new tab (or equivalent).
• When using those gestures, keep the search field populated and the result list usable so users can open several orders in a row without re-typing the query after each pick (today a single selection clears the input).
• Align expectations with flows like Spectora (and related calendar/search UX in ATT-1655) where users can work through multiple matches without losing context.

Background

• Product feedback: users expect modifier-click and context-menu behavior on search rows the same way they do on real links.
• Today GlobalSearch (attik-frontend/src/components/navbar/GlobalSearch.tsx) wires results as Autocomplete / AutocompleteItem with onSelectionChange: any selection calls handleNavigation (which uses window.open(..., '_blank')) and then setInputValue(''), which clears the search after one result.
• Result rows are not <a href> elements, so the browser does not provide standard “Open link in new tab” / ⌘+click semantics on the row itself, and there is no handling of metaKey / ctrlKey or contextmenu in that file today.
• A plain click already opens many entity types in a new window/tab via window.open, but the query is still cleared, so the core gap is gesture + context parity and optional “don’t clear on background open” behavior.
• Related calendar / address-search pain is tracked separately; this ticket focuses on global search unless product explicitly expands scope.

Scope

Frontend

• attik-frontend/src/components/navbar/GlobalSearch.tsx — primary surface: result rendering, selection handler, and how handleNavigation interacts with setInputValue and onItemSelect.
• HeroUI / React Aria Autocomplete behavior — whatever approach is chosen must play nicely with listbox selection, focus, and accessibility (keyboard vs pointer); decision needed on whether to expose real <Link href> rows (or a hybrid), synthetic context menu actions, or onMouseDown/onClick with modifier detection without breaking screen readers.
• Consistency across entity types — inspections (/inspections/:id), quotes (/work/quotes?quoteId=), contacts (/contacts/:id) should behave the same unless product intentionally differs.
• Optional stretch (only if product confirms): similar pointer semantics for address autocomplete in attik-frontend/src/components/forms/AddressSearchInputFallbackForm.tsx — those suggestions are not URLs, so “open in new tab” may not apply the same way; treat as out of scope unless explicitly added.

Product / architecture decisions (for the implementer)

• Decision needed: Should ⌘/Ctrl+click mean “open in new tab and keep search text + dropdown,” while a normal click keeps current behavior (open tab + clear), or should both preserve the query?
• Decision needed: Should right-click offer only “Open in new tab”, or also “Open in new window” / copy link — and should it mirror the exact URLs used by handleNavigation today?
• Decision needed: Mobile / touch-only users — acceptable to ship desktop-only gestures, or is a visible “Open in new tab” icon required on narrow viewports?

References

• Related UX / calendar search context: ATT-1655 (linked as related in Linear).

• Entry point: attik-frontend/src/components/navbar/GlobalSearch.tsx (handleNavigation, onSelectionChange, AutocompleteItem sections for inspections, quotes, contacts).

  Screen Recording 2026-05-14 at 9.12.58 AM.mov