Typing localhost:5173 loads HTTPS in the sidebar browser, and the address bar does not follow in-frame navigation

[JanEickholt]

I keep a SvelteKit dev server on localhost:5173, and the browser tab refuses to open it unless I type http:// first. Schemeless input goes to HTTPS, nothing is listening there, and the load just fails with nothing that says why. So my workaround is typing the scheme every single time. Defaulting to HTTPS makes sense for real sites; on loopback it's pure friction.

The second one bit me while debugging a redirect: the page inside the tab navigated itself, and the address bar kept showing what I typed, so from the outside it looked like the navigation never fired. The tab had actually moved. The real URL was sitting in the network log the whole time, and form submits, auth redirects, dev toolbars that build URLs at runtime all leave the address bar in that stale state.

Both are fixed on a branch on my fork, +102/-17 across 9 files, tests included:

• schemeless loopback addresses (localhost with subdomains and trailing dot, 127.0.0.0/8, [::1]) now go to HTTP, explicit schemes unchanged
• the address bar follows the frame's real address while the frame document is readable, and shows the existing changed-address notice when a cross-origin frame denies the read

Compare view: master...JanEickholt:deepseek-harness:browser-loopback-observed-addresses

I know external PRs aren't accepted at the moment, so I'm leaving this here. Take whatever is useful. The four specs I touched pass (21 cases); the full GUI suite shows the same two pre-existing binary-rpc failures a clean checkout has.

Anyone else typing http:// ten times a day, or was that just me?