Unframed display mode for Isolated Web Apps

at a glance

why it exists

Standard window decorations — the title bar and the system minimize/maximize/close buttons — impose fixed UI constraints that consume screen real estate and conflict with an application's own branding and layout. The two pre-existing answers both fall short (explainer — existing alternatives):

• Window Controls Overlay shrinks the title bar to an overlay but keeps a system-drawn region for the window controls. A VDI client streaming a remote desktop ends up with two stacked title bars — the remote OS's and Chrome's overlay.
• fullscreen display mode hides all browser UI but maximizes the window to the whole display — unframed windows must be able to be various sizes — and the fullscreen display mode is not available outside mobile.

Unframed mode removes the frame entirely for IWAs: fully custom title bars (Steam-on-Windows, Discord-on-macOS style), fully app-controlled secondary windows (drop-down menus, tooltips with no draggable area), and streamed remote windows without a duplicated title bar. Access is restricted to IWAs because a frameless window can spoof other applications or the user agent itself — IWAs are signed, versioned packages with a stricter trust model.

Syntax

The simplest configuration requests unframed for every window of the app. unframed is a display mode extension: it is valid inside display_override, not in the base display member — the base member keeps a normal mode (standalone here) as the fallback for user agents without unframed support. The permissions_policy manifest member requests the window-management permission that gates the feature:

{
  // 1. Request the window-management permission policy.
  "permissions_policy": { "window-management": ["self"] },
  "display": "standalone",
  // 2. Add unframed to the display_override list.
  "display_override": ["unframed"]
}

To unframe only specific windows, an entry in display_override can be a JSON object — a DisplayOverrideEntryObject — carrying the mode plus the URL patterns it applies to. That object grammar, its processing algorithm, and its fallback rules have their own reference page: display_override object entries (DisplayOverrideEntryObject).

{
  "permissions_policy": { "window-management": ["self"] },
  "display": "standalone",
  "display_override": [
    {
      "display": "unframed",
      "url_patterns": [
        "/some/path/*",
        { "pathname": "/some/other/path/*" }
      ]
    }
  ]
}

The active mode is exposed to CSS through the display-mode media feature, and draggable regions for a custom title bar are declared with the app-region property:

@media (display-mode: unframed) {
  .example-class {
    margin: 5px;
  }
}

Member reference

The feature's developer-facing surface is the display mode value itself (this page), plus two substantial contracts with stable child routes:

• DisplayOverrideEntryObject — the object form of a display_override entry: the display and url_patterns members, the URL-pattern grammar and its no-regular-expression restriction, the processing algorithm, and the fallback chain.
• app-region — the CSS property that marks regions of an unframed (or window-controls-overlay) window as draggable, so the app can build a working custom title bar.

Inputs

Outputs

• Window appearance — when unframed is the chosen display mode, the window has no window frame: no host-native title bar, no visible window controls (minimize/maximize/close), and the web contents extend to the entire window area (spec definition, quoted verbatim on the child page).
• Media query — @media (display-mode: unframed) matches inside an unframed window, so the app can restyle itself (for example to show its own title bar and window buttons) only when the frame is actually absent.
• Dragging behaviour — regions marked app-region: drag become the draggable surface that replaces the removed title bar.
• Window operations move to the app — with no UA-drawn controls, closing, minimizing, and dragging are implemented by the app programmatically where applicable; the explainer points to the companion Additional Windowing Controls proposal for those APIs.

CSS media query

The applied mode is exposed to CSS through the standard display-mode media feature: “The unframed display mode can be queried using the display-mode media feature” (spec). The query is a boolean context check over the window's own applied display mode — it takes no arguments and has no error path: it simply does not match when the window is framed. Because an unframed window's mode is fixed for its lifetime (see lifecycle), the match state of a given window does not change on navigation.

@media (display-mode: unframed) {
  /* styles for unframed mode, e.g. reveal the app's own title bar */
}

The canonical use is progressive: ship one stylesheet that keeps the custom title bar hidden in framed windows (where it would duplicate the system one) and reveals it only when the frame is actually absent. The embedded Display Mode Probe demo reports which display-mode value matches the current window.

Errors and fallback behaviour

Context and requirements

• Isolated Web Apps only — the user agent MUST restrict unframed to IWAs (spec). IWAs are signed web bundles served from the isolated-app:// scheme (WICG/isolated-web-apps), so unframed windows never appear in normal web browsing.
• Permission gate — the feature is gated behind the window-management permission, “granted by the user or via admin policies” (explainer). window-management is the powerful feature defined by the Window Management API (its Permission API integration section); the manifest request uses the IWA permissions_policy member (IWA Permissions explainer).
• Desktop platforms only — the chrome://flags entry is kOsDesktop; the ChromeStatus record lists no Android, WebView, or iOS milestone; mobile OSs are an explainer non-goal (“little distinction from full-screen mode”). The demo's install flow is documented for ChromeOS (unframed-demo, requires Chrome 146.0.7648.0+).
• Secure package context — because the app is an IWA, its content is already integrity-verified by the bundle signature; the unframed request travels in the signed manifest inside the bundle.

Window lifecycle

1. Creation without flicker — if a new IWA window's URL matches one of the unframed url_patterns, “the window should be created in unframed mode from the very beginning without flicker”: it must not show another visible display mode before switching to unframed.
2. Fixed for the window's lifetime — “once an unframed window has been created, its display mode is fixed for the lifetime of the window.” Navigating to and from URLs matching url_patterns does not transition the window in and out of unframed mode, and the same holds for URL changes through history.pushState() or window.location. (The explainer notes this may be revisited to allow dynamic changes in the future.)
3. No out-of-scope navigation — navigation to URLs outside the IWA's defined scope (including cross-origin navigation) is not permitted inside an IWA window; the user agent opens a new, regular window for the destination instead. The spec states it as a MUST NOT: the UA must not allow navigation to out-of-scope URLs to take place within the unframed window. An unframed window therefore cannot navigate across origins.

Examples

The Chrome Platform Showcase demo probes which display mode the current window reports — open it inside an unframed IWA window to see display-mode: unframed match:

A complete manifest requesting unframed only for windows under /remote/, with a custom title bar that is draggable except over its buttons:

{
  "name": "VDI Client",
  "start_url": "/session/",
  "permissions_policy": { "window-management": ["self"] },
  "display": "standalone",
  "display_override": [
    {
      "display": "unframed",
      "url_patterns": ["/remote/*"]
    },
    "window-controls-overlay"
  ]
}

/* CSS shipped inside the IWA */
.title-bar { app-region: drag; }
.title-bar button { app-region: no-drag; }

@media (display-mode: unframed) {
  /* No system title bar: reveal the app's own. */
  .title-bar { display: flex; }
}

Browser compatibility

Interim table. There is no BCD entry for unframed — BCD css/at-rules/media.json lists fullscreen, minimal-ui, picture-in-picture, standalone, and window-controls-overlay under display-mode but no unframed key (checked 2026-07-28) — and no web-features entry (webstatus.dev query, zero matches). Rows below are compiled from the linked primary sources, not from BCD.

WPT: no upstream test covers unframed as of 2026-07-28 — appmanifest/display-override-member/ carries manual tentative tests for browser, fullscreen, minimal-ui, standalone, tabbed, and window-controls-overlay, but none for unframed.

Security and privacy

• Spoofing risk and mitigation — a frameless window lets the app draw over what was previously a trusted, UA-controlled region, enabling spoofing of other apps or of the user agent itself. Mitigations: the mode is restricted to IWAs (signed, integrity-verified packages) and gated behind the window-management permission granted by the user or an administrator (spec — security and privacy considerations).
• Relocated indicators — user agents normally show the app origin and privacy indicators (camera/microphone in use) in the title bar. With no title bar, those indicators move elsewhere, at a platform-dependent location chosen by the UA; the explainer shows Chrome on ChromeOS displaying the origin in app settings and privacy indicators on the OS shelf.
• Administrator control — the ChromeStatus record lists three enterprise policies that manage the feature: DefaultWindowManagementSetting (default window-management state for all apps), WindowManagementAllowedForUrls (listed IWA origins may enter unframed mode without user interaction), and WindowManagementBlockedForUrls (listed origins are blocked, forcing fallback to other display modes).
• No new data exposure — the mode changes window chrome, not information flow: the app learns nothing about the user it did not already know, and the display-mode media query reveals only the window state of the app's own window.

Specifications

See also

• Chrome Platform Status — Unframed display mode for Isolated Web Apps (API record)
• Chromium tracking bug — crbug.com/477512407
• edman/unframed-demo — runnable demo IWA (ChromeOS install instructions)
• Additional Windowing Controls explainer — programmatic minimize/maximize/close/drag for frameless windows
• MDN — Window Controls Overlay API (adjacent: the closest existing alternative; MDN covers WCO but not unframed — its display-mode page lists no unframed value, verified 2026-07-28)
• Chrome Platform Showcase — demos for this feature
• chromeos.dev — Isolated Web Apps (platform documentation linked from the ChromeStatus summary)