[Bug]: Cmd+F does nothing in the integrated browser#22952

opened24d agobyAarmanarutiunov

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

  1. Open the desktop app and open the Browser panel.
  2. Load any page with text, for example https://en.wikipedia.org/wiki/Web_browser.
  3. Click into the page and press Cmd+F (Ctrl+F on Windows/Linux).

Expected behavior

A find bar opens and highlights matches on the page, as Cmd+F does in every browser.

Actual behavior

Nothing happens. The integrated browser has no way to search the page: no shortcut, and nothing in the browser's ⋮ menu. The only workaround is opening DevTools.

Impact

Minor bug or occasional failure

Version or commit

main @ 680152e2

Environment

macOS 26.4, T3 Code desktop (dev build from main)

Screenshots, recordings, or supporting files

The browser's ⋮ menu has no find option:

Browser more menu without a find option

Workaround

Open DevTools for the page and use its search, or open the page in an external browser.

Synced from GitHub

Fix proposed in #22960: Cmd+F opens a find bar in the integrated browser (search as you type, next/previous, match count). Find on page is also in the ⋮ menu and the command palette, and the shortcut can be rebound in Settings → Keybindings. Pages that bind Cmd+F themselves still get it first, as in Chrome.

The report is a browser shortcut bug. No duplicate with the same symptom surfaced in the open-issue check over the last 90 days.

Attempted vp run dev:desktop on main at 8acbefefc5. The seeded launch was stopped during snapshot migration; retrying with --no-seed built the web client and server, then failed in build-browser-secret.mjs: Package 'libsecret-1', required by 'virtual:world', not found. The desktop shortcut remains unverified here.

Existing proposed fix #22960 covers this report. Added via-triage; preserving that implementation rather than opening a competing PR. Leaving this issue open pending the existing PR.

Synced from GitHub

hi @juliusmarminge! gentle bump on this just in case it's been lost in the sea of issues and prs. no rush at all in case it's genuinely deprioritised for now.

but in case it was just lost, addressed all the coderabbit comments in the pr and it's up to date with main with all the conflicts resolved.

lmk if you need any changes from me whenever you have time to take another look at this. thank you!