Browser UI features

[nicoburns]

These are features that could be implemented in the Blitz browser UI (/apps/browser).

Browser UI Backlog

• Menu items:
  • Toggle incremental layout
  • Toggle element inspector
  • Toggle element outlines
  • Capture AnyRender scene
  • Capture screenshot
  • View source
  • Clear HTTP cache
• Built-in pages
  • Custom start page
  • Generic error page?
  • 404 page
• FPS counter
• Status bar
• Styling
  • Dark mode
• Keyboard shortcuts (Ctrl on Windows/Linux, Cmd on macOS)
  • T for new tab. W for close tab.
  • + / - / 0 for zoom (should remove from blitz-shell)
• Tabs (multiple embedded documents)
  • https://github.com/adamschwartz/chrome-tabs
  • Focus URL bar when creating a new tab
    (may need support for dispatching Dioxus events in response to programmatic focus)
  • Animated tab creation
  • Draggable: https://gist.github.com/alexreardon/9ef479804a7519f713fe2274e076f1f3
• Favicon support
• History + URL suggest (nucleo crate)
• Find in page
• Ad blocking using https://github.com/brave/adblock-rust
• Reader mode

[tonybierman]

Browser UI Features (#363) — Proposed Implementation Order

Principles

1. Bugs before features — performance/correctness issues compound and infect anything built on top.
2. Foundations before dependents — a status bar and built-in pages mechanism host later features.
3. Cheap, isolated wins next — ship value while the spec is still warm.
4. Architecturally invasive items last — tabs touch the document model; doing them last means each prior feature is built once on a single doc, then mechanically lifted into the tab wrapper.

Proposed Order

#	Item	Why here
1	Bug: redraws on every mousemove/scroll	Performance bug. Every later feature will be measured against current frame timing — fix first or you debug it forever.
2	Bug: scale factor text resize on Wikipedia	Correctness bug, visible. Fix before adding more UI that interacts with scaling.
3	Status bar	Chrome foundation. Find-in-page, loading state, URL hover, etc. all want to render into it. Build the host once.
4	Generic error page	Tiny. Reuses the same built-in-page plumbing as the existing 404 page. Good warmup that exercises that path.
5	Clear HTTP cache	Small menu action. Useful for every subsequent dev/test cycle.
6	Custom start page	Built-in page; simple, self-contained, immediately useful.
7	Find in page	High user value, self-contained, renders into the status bar from #3.
8	Fragment links (scroll-in-page)	Independent, common pain point, no deps.
9	Toggle element outlines	Sits next to the existing inspector toggle. Cheap after inspector exists.
10	Toggle incremental layout	Niche debug toggle, same menu surface as #9. Batch with it mentally.
11	Capture AnyRender scene	Mirrors existing "Capture screenshot" plumbing — easy once you're already in that area.
12	History + URL suggest (nucleo)	Bigger: needs persistence + fuzzy matcher. Wants the URL bar / status bar to exist first.
13	Ad blocking (brave/adblock-rust)	Meaningful network-layer integration but isolated to the request pipeline. High value, moderate cost.
14	Reader mode	Substantial content transformation. Standalone but non-trivial.
15	Tabs (multiple embedded documents)	Largest architectural change. Doing it last means every prior feature is built once on the single-doc model, then lifted into a tab wrapper — far less rework than retrofitting tabs first and rebuilding each feature to be tab-aware.

Main Tradeoff

Putting tabs last is a deliberate bet: a small amount of mechanical "make this tab-aware" work on each feature when tabs land, in exchange for shipping 14 useful items quickly. If you'd rather absorb that cost up front and have all later features be tab-native by default, we can swap tabs to slot ~3 (after the bugs, before the status bar).

[nicoburns]

Some notes on this:

• Some of these are already done: "Bug: redraws on every mousemove/scroll" and "Capture AnyRender scene", and (I think) "generic error page". I've updated the list.
• I've moved Bug with scale factor: text on wikipedia gets too large when resizing the window #404 and Fragment links (scroll in page) #405 into their own issues, as I don't think they have anything to do with the Browser UI
• I don't think "status bar" is really a foundation like claimed. Becuase we build the UI with HTML+CSS, it's pretty easy to create a bar. And they don't necessarily need to be the same UI element.
• The Menu items and Custom Pages are all small easy tasks that could be ticked off relatively easily.
• The rest of the tasks are all a bit more involved. I'd be tempted to jump straight into "tabs" or "history + url suggest" because I think those offer the most value.
• I believe Ad blocking is not just at the network layer! I think it can block dom elements too. Also, we avoid a lot of ads by not running JS anyway.

[tonybierman]

@nicoburns

Plan: Tabs (Multiple Embedded Documents) — Browser UI #363

Approach

Here's my understanding:

• The web content is rendered through a single web-view element bound to a Signal<Option<SubDocumentAttr>> (main.rs lines 357–364). Switching tabs = changing what that signal points at.
• The renderer is per-window (View<Rend> in blitz-shell/src/window.rs), shared across whatever document is active. No surface or wgpu setup changes needed.
• Per-tab interactive state (focus, hover, selection, form values, scroll) lives inside the BaseDocument itself, so keeping the doc alive between switches preserves all of it for free. We do not use replace_document() — that would discard interactive state. Instead each tab owns its own SubDocumentAttr and we swap which one the web-view is bound to.

So, the plan is:

1. Refactor existing per-browser state into a Tab struct. History, DocumentLoader, content_doc, url_input_value all become per-tab.
2. Hold Vec<Tab> + active_tab_id at app level. Chrome reads from the active tab.
3. Add a tab strip as a new Dioxus component above the URL bar.
4. Defer non-essentials (drag-to-reorder, target=_blank, pinning, persistence) to follow-ups.

Data model

// New: tab_id is monotonically increasing, never reused (so closing a tab
// can't trigger a stale signal on its old slot).
type TabId = u64;

struct Tab {
    id: TabId,
    history: SyncStore<History>,                  // existing struct, per-tab
    loader: DocumentLoader,                       // existing struct, per-tab
    document: Signal<Option<SubDocumentAttr>>,    // already exists as content_doc
    url_input_value: Signal<String>,              // currently global, becomes per-tab
    title: Signal<Option<String>>,                // NEW; populated post-parse
}

// In app(): replace the current flat state with
let tabs: Signal<Vec<Tab>> = use_signal(|| vec![Tab::new(home_url.clone())]);
let active_tab_id: Signal<TabId> = use_signal(|| /* first tab's id */);

The chrome (URL bar, back/forward, menu) reads from active_tab() instead of the current globals. The web-view element binds __webview_document: active_tab.document(). Inactive tabs' documents stay alive in their Tab entry but aren't bound to the renderer.

Implementation steps

Step 1 — Extract Tab struct and rewire single-tab path

File: apps/browser/src/main.rs

Move these existing locals into a new Tab struct: history, the loader (lines ~529–618), content_doc, url_input_value. Add id: TabId and title: Signal<Option<String>>.

In app(), hold tabs: Signal<Vec<Tab>> with one tab initially. Add a small helper active_tab(tabs, active_tab_id) -> Tab that returns the tab matching the active id (or the first tab if not found — closes a stale-id race window).

Rewire all chrome handlers (back_action, forward_action, refresh_action, home_action, the URL onkeydown, the menu actions) to operate on active_tab(). Bind the web-view's __webview_document to active_tab().document.

After this step the app behaves identically to today but with the tab plumbing in place. Verify by running it before moving on.

Step 2 — Tab strip UI

File: apps/browser/src/main.rs and apps/browser/assets/browser.css

Add a Dioxus component TabStrip above the existing .urlbar div in the render tree. Each tab renders as:

div { class: if is_active { "tab tab--active" } else { "tab" },
    onclick: move |_| active_tab_id.set(tab.id),
    span { class: "tab__title", "{tab.title.unwrap_or_else(|| short_url(&tab.history.current_url()))}" }
    div { class: "tab__close", onclick: move |evt| { evt.stop_propagation(); close_tab(tab.id); }, "×" }
}

Plus a "+" button at the strip's end:

div { class: "tab-new", onclick: move |_| open_new_tab(home_url.clone()), "+" }

CSS in browser.css: a horizontal flex container, fixed-height row, ellipsis overflow on title, distinct active style. Inactive tabs use a flat background; active tab matches the URL-bar background to feel attached to it.

The existing menu dropdown (z-index: 100) and FPS overlay (z-index: 50) sit above; the tab strip itself is part of normal flow at z-index: auto.

Step 3 — Tab lifecycle

In main.rs, add three callbacks on the tabs signal:

• open_new_tab(url) — push a new Tab, set active_tab_id to it, focus URL input.
• close_tab(id) — remove from vec; if it was active, switch to the right neighbor (or left if it was the rightmost). If closing the last tab, open a fresh home-URL tab instead of closing the window — simpler v1 behavior.
• switch_tab(id) — just active_tab_id.set(id). The reactive web-view binding picks up the new document.

Closing a tab drops the Tab, which drops its DocumentLoader, which cancels its in-flight load (existing logic at main.rs:538-540). The BaseDocument and all its DOM nodes / image cache / style state drop with it (per the document-ownership exploration: Box<Slab<Node>> is the dominant cost and is freed automatically).

Step 4 — Tab title extraction

After DocumentLoader::load_document() parses the HTML and constructs the HtmlDocument (around main.rs:582), walk the document for the <title> element and write its text into the tab's title signal. If absent or empty, the strip falls back to a shortened URL (host + first path segment).

Implementation: there's an existing pattern for querying nodes by local name — the cheapest is to walk the doc tree once after parse. (Defer prettier favicon-pulling to a follow-up issue.)

Step 5 — Keyboard shortcuts (small, optional in v1)

If easy: Ctrl+T → open new tab, Ctrl+W → close active tab, Ctrl+Tab / Ctrl+Shift+Tab → cycle. The keyboard handler already lives in blitz-shell/src/window.rs (KeyDown arm) — but intercepting these would mean adding browser-specific shortcuts above the doc layer, which is a small piece of new plumbing. Recommendation: defer to a follow-up issue unless it's trivially easy in apps/browser/src/main.rs's existing key handling.

Out of scope (deferred to follow-ups)

Deferred	Why
Drag-to-reorder tabs (chrome-tabs / Reardon gist references in #363)	Pure UX polish; the data model already supports reordering by mutating the Vec<Tab>. Worth its own issue once basic tabs ship.
target=_blank → open in new tab	Requires extending NavigationOptions (in blitz-dom) to carry target intent and threading it through BrowserNavProvider. Cross-crate, deserves its own change. The link-click handler at blitz-dom/src/events/pointer.rs:514-531 doesn't read target today.
Tab pinning, right-click menu, thumbnails, audio indicators	Out of MVP.
Persisting tabs across restarts	Needs serialization story; not v1.
Memory eviction for backgrounded tabs	Not needed until users routinely have many tabs open.
Closing last tab → quit window (Chrome behavior)	v1 keeps one tab always; the current single-window app would feel jarring otherwise. Revisit later.

Critical files

• apps/browser/src/main.rs — primary edits: extract Tab, rewire chrome, add tab strip + lifecycle callbacks. Currently lines 58–467 are the relevant app() body and History impl.
• apps/browser/assets/browser.css — add .tabstrip, .tab, .tab--active, .tab__close, .tab-new rules. Existing patterns to follow: .urlbar (line 14), .menu-dropdown (line 90), .fps-overlay (line 137).
• apps/browser/src/icons.rs — optional: add a + and × glyph if we don't want plain text, mirroring the existing IconButton pattern (lines 14–34).

Reusable existing code

• History struct (main.rs:408-467) — already a self-contained per-browser navigation stack; just instantiate one per tab.
• DocumentLoader (main.rs:529-618) — already cancels in-flight loads on new navigation; safe to instantiate one per tab.
• req_from_string() (main.rs:370-384) — URL/search parsing utility; reuse unchanged.
• IconButton (icons.rs:14-34) — reuse for the "+" and close glyphs if we prefer SVG over text.
• SubDocumentAttr (packages/dioxus-native-dom/src/sub_document.rs) — already the abstraction the web-view element binds to; keep using it.

Verification

1. Compile & basic sanity: cargo run -p browser (or whatever the existing run command is in apps/browser/README / Cargo.toml). Open the home page; confirm a single tab is visible in the strip and the page renders normally.
2. Multi-tab open & switch: Click "+", navigate to https://example.com. Switch back to tab 1 — verify the previous page is still there and at the same scroll position. Switch to tab 2 — same.
3. Per-tab history: In tab 1, navigate A → B → C, then go back to B. Switch to tab 2 (which has its own history). Switch back to tab 1; verify it's still on B with forward to C available.
4. Form state preservation: In tab 1, type into a form input on a page that has one. Switch tab. Switch back. Input value should still be there (because the doc was never dropped).
5. Close tab: Close tab 2; tab 1 stays active. Close tab 1; a fresh home tab opens (last-tab behavior).
6. Loader cancellation: Start loading a slow URL in tab 1, immediately switch to tab 2 and start loading a different URL there. Both should complete independently. Switch back to tab 1; its load should not have been clobbered by tab 2's activity.
7. No regressions: menu still opens/closes, FPS overlay still renders, screenshot capture still works, link clicks still navigate within the active tab.