[SashaMIT]

What a person sees

• The Browser window has one Safari-style bar again: window dots, back/forward, address field and actions in a single row.
• Dragging any empty part of that bar moves the window, like the title bar did. Buttons, the address field and links still work as before.
• Dragging the toolbar of a maximized or snapped Browser restores it under the pointer, and dragging to a screen edge previews and applies a snap, like a Home title bar. On a phone the press only focuses.

How

• Restores the unified-toolbar chrome for the Browser (reverts the chrome part of 3393262, "give the Browser the standard draggable Home title bar"; other windows keep the standard title bar).
• The Browser frame posts elastos.home.window-drag/v1 start/move/end messages from empty parts of .browser-chrome, using pointer capture. Each message carries the frame's home_token; a frame without a launch token sends nothing. Presses on button, input, select, textarea, a, label, form and [role=button] are ignored, as are non-left buttons and a second pointer.
• Home (attachForwardedWindowDrag in shell-window-geometry.js) acts on a message only when event.source is that window's own frame, the origin is the opaque null origin, the keys are exactly type/homeToken/phase/clientX/clientY, phase is start, move or end, homeToken equals the home_token in the route Home gave that frame (read with browserLaunchAuthority in shell-windows.js), and the window uses unified-toolbar chrome. A drag that starts on a maximized, Browser-maximized or snapped window restores it under the pointer, like a Home title bar; dragging to a screen edge shows the snap preview and releasing there snaps it. If the window is maximized, snapped or hidden by something else during a drag, the drag stops. On a phone the press only focuses. A reload or close during a drag never snaps. The listener is removed when the window is torn down. This is the PRINCIPLES.md 16 binding the window-close and navigation messages already use.
• The message is documented in docs/HOME_SHELL_HOST_CONTRACT.md ("Browser toolbar window drag", under App Messages), and the test is in that doc's Verification list.
• Cache-bust: browser.js is at ?v=browser-20261017a, style.css at ?v=browser-20261016a (capsules/browser/browser/index.html). Only v=browser- assets are cached (max-age=60, must-revalidate + ETag, elastos/crates/elastos-server/src/api/browser_capsules.rs:19-20,161-180); v=home- assets are served no-store, so the changed Home modules keep ?v=home-20260813a like the rest of home-gui. No script enforces these tokens: scripts/home-entropy-check.mjs was removed on develop in a32e3e24, and there is no browser-entropy-check.mjs.

Checks

• node --test scripts/browser-toolbar-window-drag.test.mjs: 14 pass (adds: a frame that loads again mid-drag ends the drag, 76fc08a). The new negative cases (another origin, the Home origin, another or empty launch token, an extra field, a window with no launch token, a frame without a token sends nothing) fail on the code before a136a72c and pass after.
• Chromium and WebKit (Playwright, local preview): restore-and-follow from maximized and snapped, edge snap with preview, and an unchanged System title bar. The fix commit 13764e74 passed the local pre-push gate (elastos-server lib: 3,005 passed with RUST_TEST_THREADS=2).
• home-shell-regression-smoke (Browser expects unified-toolbar; head drag kept), home-agent-shell-smoke, home-shell-bridge-smoke, check-product-data, git diff --check: pass on ea575224.
• Author's checks on 5ba9abf, not re-run here: home-phone-layout-smoke (every Browser and Home row passes on Chromium and WebKit; the only WebKit rows over baseline are the known Wallet buttons under 44 px, Required: Home on phones #92, 0.8.1); WebKit and Chromium fixture: toolbar drag moves the window by the pointer delta (-120/+80), address field still focuses, head drag +120/+80; local pre-push gate.

Branch: three feature commits (fb79807c, c7b49789, ba414024) plus a136a72c (message binding) and ea575224 (doc), and two merges of origin/develop. Not stacked on another PR.

For 0.8.1. Merge after #68 (both touch capsules/home-gui/browser/style.css).

[andersalm]

Thanks Sasha. Going into 0.8.1, first batch after 0.8.0 is published (today). Not in 0.8.0 because the release build is already being packaged and the current title bar drags correctly (installed alpha.19 check: drag exact, #87 6204914417), so this is a look change rather than a fix. The review will focus on the new frame → Home drag messages (source check, maximized/snapped states).

[SashaMIT]

This PR is parked. Anders' 3393262 on develop already makes the Browser draggable: it uses the standard Home title bar, the same as every other window.

That way has one drag path. This PR brings back the unified toolbar and adds a second path: a frame-to-Home window-drag message, with its own token binding and the renewal gap described in the body. Both versions drag the window. Develop's version keeps Home with one window chrome and one drag path (PRINCIPLES 10, 16, 17).

The branch keeps the hardened message binding (a136a72) and the host-contract doc (ea57522), in case the single toolbar comes back later. The PR is left open for its author to close.

---

Generated by Claude Code

[SashaMIT]

Not parked: kept for 0.8.1, Sasha prefers the one-row toolbar. Includes the launch-token binding (a136a72) and a fix that ends a drag when the frame reloads (76fc08a). Adversarial review PASS; gate pass.