[Request for feedback] Per-window control over unframed mode (f.k.a. borderless)

[edman]

We would like to allow Isolated Web Apps (IWAs) to display unframed windows. In this context, an unframed window is an app window displayed without the usual OS or user agent frame around the window, including the title bar, action buttons (maximize, minimize, close), or window borders. The web content is allowed full control over the window content.

The current proposal in the incubations spec introduces unframed as a general display_mode. That approach has the limitation that all windows of the IWA become unframed. Ideally an IWA can specify that some of its windows are unframed, not necessarily all of them.

Our new proposal is to do so by extending the display_override manifest field to accept JSON objects that include the display mode and a list of url_patterns where it applies. This accepts URL patterns as described in the URL pattern spec.

Example IWA manifest.webmanifest:

{
  "display": "standalone",
  "display_override": [
    {
      "display": "unframed",
      "url_patterns": [
        "/stream/*",
        { "pathname": "/popups/custom-ui/*" }
      ]
    }
  ],
  "permissions_policy": { "window-management": ["self"] },
  ...
}

The user agent follows the standard process to identify an appropriate display mode in display_override, except now it must filter modes by the given url_patterns if one is present.

When a new window initial URL matches a pattern in url_patterns, it will be created in unframed display mode from the start, preventing any "flicker" where the new window briefly shows some UI element other than the app's.

See the explainer for more information.

We welcome community feedback on this proposal.

cc @dmurph

[dmurph]

Small note: I recommend using the URLPattern json representation, used by the tabbed mode explainer, for specifying the url pattern

[DanielHerr]

It's great to be getting this feature, but it would also be nice to get a proper window management api like chrome.app.window. Not only for dev ease but also so we could do things like switch between modes like borderless and tabbed for a certain window. So devs could do things like implement a user option to use the native or custom frame like Chrome on Linux does.

But how would URLs with query or fragements work? Would it be possible to have a param in the borderless patterns and assign that in a page to switch between modes without a full navigation?

Lastly, is "borderless" the most appropriate name, or would something like "frameless" or "bare" which more accurately conveys what is being removed be better?

[edman]

it would also be nice to get a proper window management api like chrome.app.window.

The problem with using an API to select borderless is that the app must be running to call it. In some cases this is already too late, a window might already be visible, so you wouldn't be able to implement borderless without flicker, e.g. when launching the app from the launcher.

But how would URLs with query or fragements work? Would it be possible to have a param in the borderless patterns and assign that in a page to switch between modes without a full navigation?

URLPattern supports queries and fragments (called search and hash in the spec) https://urlpattern.spec.whatwg.org/#url-pattern-struct.

There are concerns with switching borderless windows on-off after creation. Mainly the performance overhead of running multiple URL pattern checks at every navigation. Our current intention is to allow it, but we might instead stick to one mode at window creation time.

Do you have use cases in mind that require this dynamic switch?

Lastly, is "borderless" the most appropriate name, or would something like "frameless" or "bare" which more accurately conveys what is being removed be better?

We might consider other names, I believe. "frameless" sounds interesting, but still quite similar in how understandable it is to "borderless". "bare" in my opinion is less understandable.

[edman]

I have edited the title and my first comment to include the latest changes in the PR.