[Bug]: Browser address bar says "Search or enter URL" but cannot search, and search text fails silently #16639

Before submitting

• I searched existing issues and did not find a duplicate. Discussion Search from the integrated browser's address bar #14470 asks for address-bar search as a feature. This report is about the address bar promising search and then failing silently.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Summary

The browser panel's address bar says "Search or enter URL", but it cannot search. If you type a search query the way you would in any browser, nothing happens or a bogus URL fails to load. The intended flow seems to be searching for content with a search engine, since the placeholder says so, not only opening URLs.

Steps to reproduce

1. Open the Browser panel on web or desktop, with either a desktop tab or an environment-hosted tab.
2. Type how to center a div and press Enter.
3. Type weather and press Enter.

Expected behavior

The text runs as a search on a search engine and the results page opens, as in Chrome, Safari, or Firefox.

Actual behavior

• Multi-word text (step 2): nothing happens. The page stays where it was, with no error or feedback.
• A single word (step 3): the tab opens https://weather/ and fails, or hangs. On a network whose DNS search domains resolve the label to a host that never answers (a campus network, here), the tab hangs for minutes.

Root cause

handleSubmitUrl passes the typed text straight to normalizePreviewUrl. That function only adds a scheme: anything without :// becomes https://<text>. No code path anywhere sends text to a search engine.

• "weather" becomes https://weather/, and "hi" becomes https://hi/.
• "how to center a div" becomes https://how to center a div. new URL() rejects that, so normalizePreviewUrl throws PreviewUrlNormalizationError (reason: "parse"). handleSubmitUrl catches it and does nothing. Its comment says "Server-side failed event renders the unreachable view", but the error happens on the client before any request is sent, so no such event ever arrives.

The placeholder promises search anyway. Mobile is at least consistent: its field says "Enter a URL" and shows an alert when parsing fails.

Notes for whoever picks this up

• The engine choice matters for environment-hosted tabs. Today Google sends those tabs to a captcha because the shell identifies as automated (see [Bug]: Environment-hosted browser tabs identify as HeadlessChrome with webdriver set, so sites like CNN and Google refuse to serve them #16638). DuckDuckGo and Bing load in those tabs today.
• Deciding whether text is a URL or a search needs to keep working for things users type now: localhost:5173, 127.0.0.1:3000/path, my-box.tailnet.ts.net, cnn.com, and pasted URLs.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.0.46-nightly.20261006.2735. Code references are at 72d5c32ba6.

Environment

The T3 Code (Nightly) desktop app on macOS 26, connected to a remote t3 serve on Ubuntu 26.04. The submit path is shared by every web and desktop tab.