The drawer bar was described across two iOS bullets, a page bullet
and an upstream-sync entry. MobileStyleAdaptation now gives it one
section: placement, the snapshot as its single source, publishing,
activation and page styling. API/Layout keeps what extension and theme
authors observe, iOSDevelopment keeps the simulator notes, and tt-docs
is regenerated.
Validation: pnpm run check.
The native bar is designed around the Duo's postures. The host now
attaches a UIHingeInteraction and draws the drawers only while the
hierarchy reports a hinge, so other iPhones and iPads keep the page's
own top bar even on iOS 27.1. The first hinge update arrives
asynchronously after the interaction is added and lays the window out
again; later updates relayout only when the hinge appears or goes away.
Validation: pnpm run check; on the iOS 27.1 iPhone Duo simulator the
outer display reports a closed hinge and shows the native bar in the
closed portrait layout. The 27.1 runtime offers no other device.
iPhone Duo keeps bar regions outside the safe area: a vertical bar
beside the content in the closed portrait and unfolded wide layouts,
and a top band beside the status bar in the unfolded tall layout. The
page's own top bar sat next to them and left that space empty.
From iOS 27.1, while the vertical size class is regular, the window
host draws the page's top-level drawers as a native glass capsule of
SF Symbol buttons in that region: the system vertical bar when
verticalBarEdge reports one, otherwise the top bar region when UIKit
lays it inside the top safe-area inset. Compact height, such as the
closed landscape layout, keeps the page's top bar.
The window snapshot announces the edge as drawerBar. drawer-bar.js
publishes each drawer's id, title, open state and mark through
set_drawer_bar_items, and a native tap dispatches
tt-drawer-bar-activate, which clicks the drawer's own icon, so opening
and hydration keep their existing path. The page hides its top bar and
the drawers slide in from the bar's edge.
Without the top bar, page content would run under the rounded display
corners. The host's content guide follows the safe area and, while it
draws the drawer bar, takes UIKit's corner-adapted top; the snapshot
insets read the same guide, so the backdrop strips and #bg1 stay
aligned. The status bar icons follow the strip on the edge that holds
the status bar.
Validation: pnpm run check; iPhone Duo simulator on iOS 27.1 in the
closed portrait, closed landscape, unfolded wide and unfolded tall
layouts.
Use resource identity for thumbnail state and distinguish stale refs from unexpected errors. Append image diagnostics before deciding whether MCP results are empty, and reuse shared role, media and workspace helpers.
Use the capture filter's geometry consistently, share mobile plugin transport, and remove redundant state, error variants and test assertions. Update the API and architecture documentation to match.
Validation: pnpm run check; focused frontend, Gemini, MCP, image and byte-stream tests; Android debug APK build.
Expose native content viewport PNG bytes through api.layout.capture(). Use ScreenCaptureKit for the macOS WebView's own process window, WK snapshot on iOS, CapturePreview on Windows, WebKitGTK on Linux, PixelCopy on Android and the existing window-layout bridge on OpenHarmony. Keep geometry and image processing with callers and propagate native failures.
Tauri and wry expose native WebViews but no capture API. Declare the already-locked WebView2/Windows and WebKitGTK/Cairo packages directly for those platform calls; no new package versions are introduced.
Validation: pnpm run check; Rust crate boundaries; standard macOS, iOS simulator and Android emulator dev builds; native/system pixel comparisons and timing on all three; Web Host Unsupported response; diff check. Windows, Linux and OpenHarmony runtime validation remains for their native environments.
Bring OpenHarmony onto the contract Android and iOS already follow.
ArkUI lays the Web out in the safe area, ArkWeb's RESIZE_CONTENT
shrinks the layout viewport by the docked keyboard's overlap, and an
app-owned window-layout plugin publishes window snapshots and draws
wallpaper strips behind the system bars.
- Share the window-layout plugin transport between Android and OHOS.
- Drop the remaining OHOS branches in Rust and the frontend.
- Rotate with the sensor, within the system rotation lock.
The ability and plugins-workspace pins point at the Darkatse forks
until LeenHawk/openharmony-ability#1 and LeenHawk/plugins-workspace#1
merge.
Consume system bars, cutouts and docked keyboards in Android and iOS,
then let web content use the resulting viewport. Publish window wallpaper
strips through one shared background path.
Remove the old CSS and IME compensation layers, update layout ABI v2,
and keep the matching documentation and behavior tests together.
