Context
The default in-OS Browser uses the server-side proxy tier (routes/desktop_browser/proxy.py + rewriter.py): it fetches the page, rewrites URLs, and serves it in a sandboxed iframe. Recent fixes made this tier handle more:
The structural limit
The proxy tier rewrites server-rendered HTML. It fundamentally cannot drive the large class of sites that submit search/navigation via client-side fetch()/XHR from inside the sandboxed iframe (most modern SPAs, JS-driven search, infinite scroll, anything behind heavy client routing). The service worker catches some same-origin fetches, but full interactivity (logins with JS, JS consent walls, dynamic apps) isn't something the proxy should chase indefinitely — each is a fresh edge case.
Proposal
Treat the proxy as the lightweight / read-mostly tier and build interactive browsing on the planned escalate-to-real-Chromium tier (streamed Chromium / Neko-style on a cluster node — see the hybrid-browser design). When a page needs real interaction, escalate the tab to a real browser session instead of extending the proxy.
Scope to define here
- Escalation trigger (user button + heuristics: JS-form detected, repeated proxy form failures, known-SPA domains)
- Session lifecycle + which cluster node hosts Chromium
- Shared user/agent control (bidirectional) — ties into the hybrid-browser spec
- Cookie/profile continuity between proxy tier and escalated session
Out of scope
Further proxy form-handling beyond GET/POST HTML forms — those are done. Anything JS-driven is the escalation tier's job.
Context
The default in-OS Browser uses the server-side proxy tier (
routes/desktop_browser/proxy.py+rewriter.py): it fetches the page, rewrites URLs, and serves it in a sandboxed iframe. Recent fixes made this tier handle more:The structural limit
The proxy tier rewrites server-rendered HTML. It fundamentally cannot drive the large class of sites that submit search/navigation via client-side
fetch()/XHR from inside the sandboxed iframe (most modern SPAs, JS-driven search, infinite scroll, anything behind heavy client routing). The service worker catches some same-origin fetches, but full interactivity (logins with JS, JS consent walls, dynamic apps) isn't something the proxy should chase indefinitely — each is a fresh edge case.Proposal
Treat the proxy as the lightweight / read-mostly tier and build interactive browsing on the planned escalate-to-real-Chromium tier (streamed Chromium / Neko-style on a cluster node — see the hybrid-browser design). When a page needs real interaction, escalate the tab to a real browser session instead of extending the proxy.
Scope to define here
Out of scope
Further proxy form-handling beyond GET/POST HTML forms — those are done. Anything JS-driven is the escalation tier's job.