Seen live on the shared app: "domain" on example.com showed "2/2" for the first of two matches, and "2 matches" after Next. `ICoreWebView2Find::ActiveMatchIndex` starts at 1 (-1: none); `FindState::from_webview2` converts it (tested), so the bar reads 1/2, then 2/2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Host: `safe.rs` is a flag in this process's memory, never written to disk, so the next normal start is back to the owner's setup. While it is on a site tab gets the tab bridge and nothing of the app's page layers: its document-start scripts are `SiteHooks::safe_init_scripts` (default: the bridge alone) instead of `init_scripts`; `site_page_loaded`, `tab_placed` and `tab_background` are not called; `page_scripts` is empty; `eval_in_site_tabs` does nothing. So no page runtime, plugins, theme, custom CSS, feature flags, fixes, hotfix data or words reach a page: the site runs as in a browser, and only the shell is the app's. It starts from the launch argument `--safe-mode` (for when the interface itself is broken), from Shift held while the app starts (Windows), or from the shell: `safe_mode_get` / `safe_mode_set {on}` (shell-only), where a switch rebuilds every tab webview (profiles marked stale, `tabs-rebuild` asks the shell for its layout) so document-start scripts change too. Tests: the argument, the flag, and that app.rs and host.rs gate every layer.
Frame: the app menu's "Restart in safe mode…" says what it does before anything reloads; while on, the titlebar shows an amber "Safe mode | Leave" chip (one click leaves) and the row reads "Leave safe mode"; the chrome drops its theme (and pane themes) and takes it back on leaving, without touching the first-frame cache. `features.safeMode` (on by default).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Host: `tab_find {id, action, query}` (shell-only; start, next, previous, stop). On Windows it drives WebView2's own find (`ICoreWebView2Find` from `ICoreWebView2_28`, find options from `ICoreWebView2Environment15`; its built-in find bar suppressed, all matches highlighted) and reports the engine's match count and active match to the shell as `tab-find` events. On macOS, Linux and an older WebView2 Runtime native code evaluates the engine's `window.find` in the tab instead (next and previous work, no count); WKWebView's and WebKitGTK's native find are not wired here because this tree cannot be compiled or run for them on this machine. The query is one typed line (1..=256 characters, no control characters), goes to the engine and is kept nowhere. Tabs gain no command: a tab forwards the existing key name `find` (Ctrl+F) through tab_shortcut.
Frame: FindBar.tsx takes the address field's place in its pane's toolbar while open, so the page does not move and in split view the bar is the searched pane's. "3/17" where the engine counts, "No matches" for none; Enter / F3 next, Shift+Enter / Shift+F3 previous, Esc closes, clears the highlights and gives the page the keyboard. `features.find` (on by default) gates the menu row, the palette entry and the keys. Only what the page has rendered can be found, as in a browser.
Also: this makes `pub mod find` in lib.rs (already in HEAD) resolve again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Frame: AppMenu.tsx is a menu at the end of the titlebar cluster (before the caption buttons; macOS has none there). Its rows are `ShellSite.menu`: ordered groups of built-in rows by name and the app's own ({id, label, icon, shortcut, hint, when, checked, run | submenu}); `DEFAULT_MENU`, `menuWith` and `menuWithout` order, add and remove. A built-in row shows only when the app serves it (decks, `menu.languages`, themes, `menu.modes`, and `features`: zoom, store, workspaces, developer, updates), so no app gets a dead row. Language, Theme, Mode, Workspaces and Developer are submenus; Language and Theme apply live and keep the menu open, Mode asks the same keep-my-changes question as Settings (panel `menuModes()`). Keyboard: arrows, Home/End, type-ahead, the arrow along the reading direction opens a submenu, Esc closes one level; ARIA menu roles; submenus stay inside the window; one highlight for pointer and keys. It is an overlay like the other shell menus (the shell is raised, panes stay visible, nothing is dimmed).
Words: menuMessages.en.json (`wb.menu.*`), read through the framework i18n with that English as the fallback until the catalogs have them; words the panel already has are reused.
Host: `tab_zoom {id, factor}` (shell-only) sets a tab's page zoom with the engine's own zoom, clamped to 25%..500% and remembered per tab id in app data `zoom.json` (a number per tab id, nothing else; a closed tab's entry goes); without a factor it reads. A tab may forward four more shortcut names: `app-menu`, `zoom-in`, `zoom-out`, `zoom-reset`. The titlebar shows a zoom chip only while the pane in front is not at 100%.
create-waybetter: `tab_zoom` in the shell capability list; the template says which panel sections it lacks (store, updates) and how to add menu rows.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
layout.rs (headless, tested): Placements remembers each tab webview's last rectangle and
visibility, so a tabs_sync that changes nothing makes no native call and one that moves one
pane touches one webview; Frame/follow_rect estimate where panes go when the window size
changes (outer margins fixed, proportional in between, shared borders stay shared).
host.rs: place_tab/forget_tab use it; place_child is a single set_bounds (one WebView2
SetBounds instead of a move then a resize, each a page re-layout); follow_window_resizes
re-places visible tabs from the window's own Resized events on the main thread, before the
shell lays out again, and keeps WindowMetrics current so a sync needs no blocking round
trips for the window size; layout_window says when a layout was made for a stale size.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Linux: the shell becomes a GtkOverlay layer itself (an empty box is the base) and is
re-ordered to the top or bottom of the overlay; a tab placed while it is raised goes under
it. macOS: the shell's WKWebView is re-ordered among its superview's subviews
(addSubview:positioned:relativeTo:), keeping the first responder if it was in the shell.
Both now report support, so overlays no longer hide the tabs there either (the app makes the
shell webview transparent; macOS needs tauri's macos-private-api).
Windows: a tab webview about to be hidden hands the shell its last frame (WebView2
CapturePreview, JPEG, `tab-still` event), for its pane to show instead of an outline while
no webview is on screen there.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Shell overlays can then draw over the panes while they stay on screen.
Returns false elsewhere, where the caller hides the tabs instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tao's thread event target and the single-instance message window are visible
1 px unowned top-level windows. taskkill /PID (WM_CLOSE, no /F) closes only the
first such window in z-order; a minimized app window sinks below them, so the
close destroyed a helper and the app kept running. route_helper_closes
subclasses those helpers and forwards WM_CLOSE to the app window.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tauri 2 (runtime-wry build_gtk with the window's GtkBox) packs every child
webview into the window box, stacked and with set_position/set_size ignored,
so tab webviews landed under the shell instead of over their panes.
place_child/attach_shell move them into a GtkOverlay (shell as base layer)
and allocate each at its exact rect via get-child-position; placed_rect
reports the placement (GTK children have no position). Windows/macOS keep
set_position/set_size.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
set_tab_visible shows/hides a tab webview and sets
ICoreWebView2_19::SetMemoryUsageTargetLevel (LOW when hidden, NORMAL when
shown). Hidden tabs keep running; the browser trims their working set.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
read_json::<T>(app, name) did not compile with two explicit generic
parameters; the app's call sites name only the value type.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Site-agnostic parts of the X app, behind a small site adapter:
- crates/waybetter-host: webview-label security policy and tab rect
clamp, account profiles with native-owned accounts (AccountRules),
plugin store with bundled-plugin upgrades (PluginHost), signed
data-only hotfix channel, update scheduling and crash handshake, tab
payloads/link routing/tab-chrome validation, and (feature "tauri")
webview helpers and the Windows system menu.
- packages/runtime: DOM hub, request hub, plugin API core, OKLab theme
color model, split-view rail hiding, link routing and account
reporting, each configured by a SiteAdapter.
- packages/shell: address bar, pane, link-drop, profile, palette and
update-chip models, and window controls with the Tauri API injected.
Tests moved/adapted from the app: 45 Rust (headless), 40 TypeScript.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
