Contact emails
[email protected], [email protected]

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 (eg links to known github issues in the project 
for the feature specification) whose resolution may introduce web 
compat/interop risk (eg, 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.

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a57980d.712dbee4.e31b3.029c.GAE%40google.com.

Reply via email to