Borderless mode

[sonkkeli]

こんにちは TAG-さん!

I'm requesting a TAG review of borderless mode.

Currently all the possible app display and display_override modes rely on apps having at least some format of a title bar - something between the full Chrome title bar and currently most minimized window-controls-overlay (WCO). Despite WCO having some same qualities as what we are trying to achieve, it is still not offering enough flexibility for some use-cases. To enable such use-cases, this explainer will explain how the title bar will be completely removed and so-called borderless mode enabled. This way the title bar area is replaced with web content and so giving the developers full control on how the title bar would look like.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/manifest-incubations/blob/gh-pages/borderless-explainer.md
• User research: [url to public summary/results of research]
• Security and Privacy self-review²: [url]
• Primary contacts (and their relationship to the specification):
  • Sonja Laurila (sonkkeli@), Google
  • Dan Murphy (dmurph@), Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5551475195904000

Further details:

• [ ] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): Google
• The group where standardization of this work is intended to be done ("unknown" if not known): WICG/manifest-incubations
• Existing major pieces of multi-stakeholder review or discussion of this design:
• Major unresolved issues with or opposition to this design:
• This work is being funded by:

You should also know that...

This feature will only be available for Isolated Web Apps.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify sonkkeli, dmurph

[cynthia]

We discussed this during our vF2F. While we see potential use cases which could benefit from this functionality, we'd like to discuss a couple things that are points of concern.

First of all, this depends on a feature that no other implementation has provided any signal on - which somewhat jeapordizes its future path on the web platform. We'd probably want to hear some level of feedback from other implementors on the dependency proposal (IWA) as it is a architecturally complex topic which we should carefully approach.

Even if this is gated behind a protected context of some form (IWAs?) - draggability should be a key consideration, especially the guarantees of having the user to be able to do so. The proposal as it stands does not seem to have mitigations from applications (be it malicious or not) breaking usability by making undraggable windows - and we believe that is not a positive pattern. Similar situation with the window controls. Reading the IWA explainer, we had a hard time understanding how that as a mechanism can prevent bad patterns coming from user-experience degrading applications.

We are also concerned that the feature introduces a sharp cliff in terms of usability: While many use cases are as simple as adding a control to the title bar, there is no way to do this without recreating the entire title bar, windowing controls and all. It would be better to introduce a layered solution, that makes simple cases easy and complex cases possible.

The drag feature being coupled to a webkit-prefix style is definitely not a recommended pattern, and unless this is a prototype/trial, having yet another feature depend on a webkit prefixed feature is a pattern we should avoid.

And we would recommend you have a conversation with the Second Screen working group, who are working on Fullscreen Popup Windows. Their use case is slightly different, but it would be good if you could align your approaches and attributes. @bradtriebwasser, @michaelwasserman, @inexorabletash, and @anssiko are your main contacts for that.

Finally, we see there is no discussion about the accessibility risks associated with removing the window controls from the user interface. This can have detrimental effects on the usability in the context of AT needs.

P.S. A web platform explainer should not have any Googler-only links.

[sonkkeli]

Thank you for your detailed feedback. We agree that probably it makes sense to first go through the IWA review before a feature which depends on it strongly. Here’s some pointers to the feedback. Let me know if there's more concerns raised in regards to anything.

IWAs It is important to note that the borderless feature is primarily designed for use in high-trust environments (IWAs) and not intended for the broader web platform in its current form. In the event that we’d consider expanding its use to the broader web, additional mitigations and fallbacks to address potential risks should definitely be explored. Our main goal w.r.t. the web platform is making sure that this design doesn't prevent future mitigations or fallbacks in the future if they are needed.

Webkit-prefix Someone from Microsoft is working on addressing this issue crbug.com/1447586.

Draggability Actually in some scenarios, non-draggable windows are the desired outcome, such as for when the app wants to open non-draggable modal dialogs or right-click menus from the VDI session. I made a PR to highlight such use-cases better in the explainer.

Sharp cliff There is already the existing Window Controls Overlay feature which can be seen as the “simple case” for most users providing minimal draggable area. However, as discussed on the explainer this would not be sufficient for our trusted partner's use cases.

Accessibility Web content allows the creation of accessible websites. We would expect our trusted partners to leverage the existing capabilities (together with the upcoming AWC) to ensure accessibility in their isolated web apps. This is something I added to the new accessibility section in the explainer. However we want to make sure that we are not missing something and we’ll make sure to contact our accessibility experts at Google again. During the launch process there was already an internal accessibility review step which was approved.

Fullscreen Popups We’ve brought this explainer to the attention of the Second Screen WG, but there are relatively few parallels between this IWA manifest display-mode proposal and the window.open() fullscreen feature proposed in Fullscreen Popup Windows. While they share a permission and some security considerations, this application setting relies on the additional trust of Isolated Web Apps, and fullscreen popups mainly offer a new entrypoint to the transient HTML Fullscreen window state.

[mgiuca]

(Non-TAG member with a few comments)

designed for use in high-trust environments (IWAs) and not intended for the broader web platform in its current form

I think the explainer/spec could be written to avoid directly depending on IWAs and instead just use a more generic idea of a "high-trust environment". Leave it unspecified but state that the user agent "MUST" only expose this in environments where the user has indicated through some unspecified mechanism a higher degree of trust in the application.

This is a stop-gap measure. We really need a way, in general, of talking about "high-trust contexts" in specs which have well-understood definitions, and can therefore pave the way for user agents to introduce things like IWAs which fit that definition, without literally prescribing that the APIs need to be exposed in IWAs.

There is already the existing Window Controls Overlay feature which can be seen as the “simple case” for most users providing minimal draggable area.

I agree, I think WCO feature provides Alan Kay's "simple things easy" whilst Borderless provides the "complex things possible" use cases. However, in line with comments I made in March on the pull request, I think that justification means that Borderless should act as an extension of WCO rather than being quite a different design. To me, that means using a similar user-opt-in mechanism (a toggle control on the border itself, which then clearly denotes how to "untoggle" it via an animation), rather than a permission prompt for something that is fundamentally not a permission, but a different UI mode.

[torgo]

Hi @sonkkeli we discussed today in our TAG breakout. We don't think this should be standardized in it's current form on the web platform. We understand the use case. However there is a dependency on the idea of "trusted" applications - and this is an area that is in development - e.g. isolated webapps which we're also concerned with and is currently not stable enough for other things to be built on top of it. In any case, we are concerned with the lack of agency of the user - e.g. with dragability and accessibility issues. We're going to close this review for now.