Intent to Ship: Unframed display mode for Isolated Web Apps

[Chromestatus]

Contact emails

edm...@google.com, swetha...@google.com

Explainer

https://github.com/WICG/manifest-incubations/tree/gh-pages/unframed-explainer.md

Specification

https://wicg.github.io/manifest-incubations/index.html#dfn-unframed

Design docs

https://github.com/WICG/manifest-incubations/blob/gh-pages/unframed-explainer.md

Summary

Unframed display mode allows [Isolated Web Apps](https://chromeos.dev/en/web/isolated-web-apps) to occupy the entire browser window, which optimizes the workspace available. By removing standard window borders and title bars, developers can implement unique user experiences with branding and menu hierarchies that match the look-and-feel of native applications. Administrators can manage this feature with existing policies for window management: - [DefaultWindowManagementSetting](https://chromeenterprise.google/policies/#DefaultWindowManagementSetting) configures the default state for the window management for all apps. The policies below can override this default. - [WindowManagementAllowedForUrls](https://chromeenterprise.google/policies/#WindowManagementAllowedForUrls) allows IWAs with specified origins to enter unframed mode without any user interaction. - [WindowManagementBlockedForUrls](https://chromeenterprise.google/policies/#WindowManagementBlockedForUrls) blocks unframed mode for IWAs with specified origins, forcing Chrome to fallback to other available display modes.

Blink component

UI>Browser>WebAppInstalls>Isolated

Web Feature ID

No information provided

Motivation

Standard window decorations, including the title bar and system control buttons, impose fixed UI constraints that restrict available screen real estate and visual integration. Without unframed mode, developers are forced to design around standard operating system frames that often conflict with an application’s specific branding or functional layout requirements. While the Window Controls Overlay API provides a lot of flexibility, it still enforces system-drawn regions for window controls, which prevents a fully bespoke interface. Unframed mode enables Isolated Web Apps to occupy the entire window surface, bridging the gap between web and native application experiences. This level of control is essential for immersive software - such as virtual desktop clients - that requires a unique visual hierarchy or a maximized workspace. By removing standard window borders and title bars, developers can implement unique user experiences with branding that matches the feel of native applications.

Initial public proposal

https://github.com/WICG/manifest-incubations/issues/118

Search tags

unframed, display mode, display override

TAG review

TAG review is not required for IWA features, see https://chromium.googlesource.com/website/+/HEAD/site/blink/launching-features/isolated-web-apps/index.md#who-do-i-request-feedback-from-for-iwa_specific-apis

TAG review status

Not applicable

Goals for experimentation

Risks

Interoperability and Compatibility

The interoperability risk is low for the standard web, as this feature is restricted to Isolated Web Apps (IWAs). The primary risk is that other browser engines may choose not to implement this specific display mode due to long-standing security concerns regarding system UI impersonation (phishing) when an application can hide all host-provided frames. IWAs mitigate these concerns through an enhanced trust and installation model that is not available to standard web origins. Compatibility risk is negligible. "Unframed" is an opt-in value within the display_override manifest field. Browsers that do not recognize the "unframed" value will ignore it and fall back to the next supported display mode in the list (typically "standalone" or "minimal-ui"), ensuring the application remains functional.

Gecko: No signal

WebKit: N/A

Web developers: Strongly positive This feature is crucial for our VDI partners.

Other signals:

Ergonomics

N/A

Activation

N/A

Security

The primary security risk of unframed mode is UI spoofing. By removing the user-agent title bar and window controls, a rogue application could attempt to impersonate operating system UI, browser chrome, or the interface of a different application to perform phishing attacks. This risk is mitigated by restricting the feature to IWAs, and relying on the IWA trust model.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

N/A

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
This feature is only supported in ChromeOS. The title bar includes privacy-relevant information. In ChromeOS we can make them available in other parts of the OS UI, but we can't do the same in other platforms.

Is this feature fully tested by web-platform-tests?

No
There are Web Platform Tests to verify the display mode exists. Browser tests and unit tests for verify the feature in more detail.

DevTrial instructions

https://github.com/edman/unframed-demo

Flag name on about://flags

enable-unframed-iwa

Finch feature name

UnframedIwa

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

True

Tracking bug

https://crbug.com/477512407

Launch bug

https://launch.corp.google.com/launch/4211065

Measurement

UseCounter(WebFeature::kUnframedIwa) https://chromestatus.com/metrics/feature/timeline/popularity/5764

Availability expectation

Feature is available only in Chromium browsers in ChromeOS for the foreseeable future.

Adoption expectation

Feature is used by at least two partners within 12 months of launch in Chrome.

Adoption plan

Work with partners: The feature is currently available behind a feature flag in Chrome, and two partners already use it to develop new IWAs. The target release of their IWAs is 26Q4. Public documentation: We intend to write articles for the feature in https://developer.chrome.com/docs/iwa/.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

N/A

Estimated milestones

Shipping on desktop	152
DevTrial on desktop	146
Rollout step 1	152
Rollout step 2	152

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

N/A

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5551475195904000?gate=6107103651954688

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4ad86ea7-a144-4f95-b66f-7d457448143en%40chromium.org

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a57980d.712dbee4.e31b3.029c.GAE%40google.com.

[Reilly Grant]

IWA OWNER LGTM

This is an extension of existing APIs which allow a PWA to control more of the window presentation, but the ability to completely remove the window controls carries spoofing risks which make the IWA requirement appropriate.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8KFNXm0-CDtz4nO9MWE_P3xvRB5j0N9r562%3DhdHM4%3DzA%40mail.gmail.com.