Two bugs, one line apart, both silent.
The `url(/…)` rule only matched an UNQUOTED target, so `url("/fonts/x.woff2")` — the form every
generator emits — went through untouched. And it only ran on HTML, so a linked stylesheet got the
narrow `/_bun/` rule and nothing else.
Together that meant a site's own @font-face rules kept pointing at `/fonts/…`, which inside the frame
is the platform's root. Every face 404'd and the preview rendered in a system fallback: nothing looked
broken, it just looked like a different site than the one being previewed.
JavaScript keeps the narrow rule — an absolute path in JS may not be a URL. In CSS it always is.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Responsive images 404'd in every preview, and did it silently.
The attribute rule matches a whole attribute value, so it could never have handled srcset — that is a
comma-separated LIST of "url descriptor" pairs, and prefixing it as one value would mangle the first
descriptor onto the first URL. It did not match srcset at all.
Silently is the operative word. An <img> with a srcset also has a src, and the src WAS prefixed — but a
browser given a valid srcset chooses from it and never looks at src. So the markup read correctly, one
attribute pointed at the platform root, and the image was just missing. Found by a logo that would not
load in the fofos layout preview.
imagesrcset is rewritten too. That is the one on <link rel="preload" as="image">, easy to miss and
expensive to miss: a preload that 404s costs a request and leaves the real image undiscovered until the
body is parsed, which is the opposite of why anybody adds one.
Six tests, including the case that found it — src prefixed, srcset not, image missing — and a
protocol-relative candidate left alone, which is the rule everywhere else in this file.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The panel knew one URL: the one you typed. Navigate three pages into an app and the
header still showed the front door, "open in a new tab" still went there, and a
reload — which fires by itself whenever a dev server restarts — threw away where you
were and started again at `/`.
Now the app reports where it is, and a reload composes it back.
── How the panel finds out ──
The frame is same-origin for a proxied preview, so `contentWindow.location` is
readable. It is PUSHED rather than read, because a dev server is an SPA: a route
change is `history.pushState`, which fires no event and never reloads the document.
Polling would have to be constant and would still lag. The script the proxy already
injects now patches `pushState`/`replaceState`, listens for `popstate`/`hashchange`,
and posts the path — with the proxy prefix stripped, since that is plumbing and the
panel should not have to know about it to show a URL.
Only proxied previews can do this. A cross-origin frame reports nothing, and grafting
a remembered path onto someone else's host would be inventing a URL, so `targetUrl`
composes only when there is a port.
── Two fields, and the loop that forced them ──
`url` is what you pointed the panel at; `current` is where it has got to. The obvious
design is one field — a browser has one address bar — and it feeds itself: the stored
value IS the iframe's `src`, so recording a route change hands the frame a new `src`
for the page it is already showing, which browsers treat as a navigation. Every click
would cost a reload.
Belt and braces, because one of the two would be enough only until someone changed
the other: the fields are separate, AND `PreviewFrame` captures its `src` at mount
and ignores later changes. Remount-by-key is still how a reload happens.
`ev.source` identifies which frame is talking. `message` is a window-level event and
two same-origin previews hear each other; comparing the posting window to this
iframe's `contentWindow` is exact, where matching on URL would break the moment two
panels pointed at the same port.
Writes are debounced 800ms. `useDashboardState.setValue` PATCHes the server on every
call and an SPA emits a route change per click; the value is only read at mount, so
being a second behind costs nothing.
Also: the header shows `localhost:3001/settings` rather than
`api/dev-proxy/3001/settings`, and editing starts from that — one is a thing you can
retype, the other is not.
── Tests ──
The reporter is RUN, not string-matched: `new Function` against a fake window, which
also means a syntax error in the injected script fails the suite rather than silently
breaking every proxied page. Covers prefix stripping, the app root reporting `/`
rather than empty, query and hash surviving, the report on load, pushState, and
popstate. Plus the composition helpers, including that an ordinary URL is never
composed with a path.
── One stale comment corrected while in there ──
The file claimed `allow-same-origin` "is present, and has to be". There is no
`sandbox` attribute at all, so nothing was present — and a sandbox with
`allow-same-origin` plus `allow-scripts` is worth roughly nothing anyway, since the
frame can remove its own sandbox attribute. Now says that.
Not verified against a live dev server through the real proxy — that needs the server
restarted with this code. tsgo clean, 934 pass / 7 fail unchanged, frontend builds.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The blank preview, and it was never the restarts. Bun's dev server emits
href="/../../../chunk-qmw09gd9.css"
Root-absolute AND climbing. Prefixed naively that is
`/api/dev-proxy/3001/../../../chunk-…`, which the BROWSER normalises straight back
to `/chunk-…` — the platform root, where it 404s. Two failed asset requests, a
white pane, and nothing in the network tab suggesting a proxy was involved. The
rewrite looked correct in isolation and was undone by whoever read it.
`..` is resolved by the consumer, so it has to be resolved before the prefix goes
on. Both halves do it now: `rewriteHtml` for what is written in the document, and
the injected script for URLs built at runtime, which Bun also emits in this shape.
Verified through the whole stack against the real app on 3001: document 200, both
assets 200 with `text/css` and `text/javascript` — where before they were 404s at
the platform root.
13 tests, and one of them asserts the failure rather than the fix: that
`/api/dev-proxy/3001/../../../chunk-x.css` really does resolve to `/chunk-x.css`.
Without that line the other tests look like arbitrary string manipulation.
── Separately, and not a bug in this code ──
Two processes were listening on 3001, holding DIFFERENT task output files
(`b0oe99a47` and `b6zat0x7e`) — two independent jobs, not one restarted. Bun allows
both to bind through SO_REUSEPORT, so requests were split between them and stopping
one legitimately left the other serving. That is worth knowing before reading a
Stop as broken, and it is the second time today SO_REUSEPORT has made a duplicate
invisible.
tsgo clean, frontend builds, 914 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5