v150 · Window Management
Additional Windowing Controls
The current Window Management Working Draft proposes window.minimize(), window.maximize(), window.restore(), and window.setResizable() for installed web apps, plus the display-state and resizable media features. ChromeStatus currently records a developer trial behind a flag with no milestone; this historical v150 route is retained as a stable identity, not a shipment claim.
concepts
-
Window State Controls
The core JS surface: buttons that call
await window.maximize(),minimize()andrestore(). Each button invokes an exposed Promise-returning method, or reports that the method is unavailable; real resolutions and rejections remain distinct. -
display-state Media Feature
A live read-out of
matchMedia("(display-state: …)")across all four values —normal,minimized,maximized,fullscreen. AMediaQueryListchangelistener updates the panel the moment the window state flips, exactly how a custom titlebar toggles its maximize/restore button. -
Resizable Lock
Where implemented in an installed app, call
await window.setResizable(false)and observe theresizablemedia values. The proposal distinguishes blocked user resizing from Web APIs such asresizeTo(). -
Custom Titlebar
The VDI use case end-to-end: a bespoke titlebar drawn in HTML with
app-region: drag, non-draggable window-control buttons wired to the AWC APIs, and CSS@media (display-state: maximized)rules that swap the maximize and restore buttons automatically.
why it is proposed
Virtual Desktop Infrastructure clients and custom-titlebar apps need a dedicated way to relay minimize, maximize, restore, and user-resizability intent to the host window. The proposal would let installed apps request those operations through permission- and policy-checked methods, then react to genuine host state through media features that are not themselves permission-gated. Promise resolution, permission state, media-query state, and operating-system cooperation remain separate signals; none alone proves that a requested transition occurred.