Add Additional Windowing Controls API to the spec

[patrykchodur]

This commit adds the Additional Windowing Controls API to Window Management spec.

---

Preview | Diff

[michaelwasserman]

Nice, let split the PR, since it's easier to review and accept the separate Explainer and security and privacy files, which should be marked as experimental enhancements to this spec. Are those direct copies of https://github.com/explainers-by-googlers/additional-windowing-controls files? From a cursory glance there seem to be some extra line breaks?

Updating the index.bs spec file will have a higher bar, since most existing content reflects functionality that was reviewed by W3C groups (Second Screen WG, TAG, privacy, security, accessibility, CSS, etc.) and has already shipped by default in Chromium. We'll likely want to mark any separate PR's spec changes as experimental, and request similar reviews through an dev trial and origin trial incubation process. +CC @anssiko and @tidoust who might know the right way to coordinate this effort with the Second Screen WG and kick off the right reviews for incremental enhancements.

Please also share some context about the ongoing Chromium experimentation, is the Explainer's limited standalone/minimal-ui display-mode and user activation requirements up to date? (those should be reflected in the spec algorithms). Folks will likely appreciate more color around the "Platform support explanation"; are we anticipating support on all desktop platforms before or during any upcoming OT? Have we explored Android freeform desktop windowing mode support? Any anticipated limitations should be clearly defined.

I'll. take a closer look after those initial points are addressed.

[anssiko]

Thanks for the contribution.

I assume web-platform-tests/wpt@1b61e4e matches this PR.

At Working Draft stage, failing tests in https://wpt.fyi/results/window-management is an appropriate way to signal experimental status of a feature. Such features can be manually marked as experimental in the spec too, but that’s not a requirement at WD.

When significant changes are made to the spec, from time to time, we will seek review feedback from various horizontal groups in a non-blocking manner.

Smaller PRs do help this WG review the contribution in a timely manner.

[patrykchodur]

Thanks for taking a look!

---

The Explainer and security and privacy files are just copies from the https://github.com/explainers-by-googlers/additional-windowing-controls with just removing a leftover about the window.onmove event from the security and privacy questionnaire

5c5
< The features exposes the display state of the window (minimized/maximized/normal/fullscreen), an event fired when the display state changes, an event fired when the window moves, and whether the window is user resizable.
---
> The feature exposes the display state of the window (minimized/maximized/normal/fullscreen), an event fired when the display state changes, and whether the window is user resizable.

The algorithm already mentions transient activation, but not the standalone/minimal-ui display-mode. I basically want the feature to be available in any standalone web app window. For example, Isolated Web Apps want to add a a new unframed display-mode, and it should work there as well. Do you know how to phrase it nicely? In terms of Chromium codebase, it's called being in the web app scope (see here). I can either list all the applied display modes or try to come up with a formal definition of the web app scope. I couldn't find an existing one, but I might have missed something.

For the Platform Support I was planning to release it initially on ChromeOS because there's already a high business need for it, and from the Chromium codebase we have the most control over the host operating system window transitions. It works quite well on X11 Linux, Windows and MacOS with some flakyness in the browser tests, but that might be a problem with the test suite. From my manual testing it worked fine. Wayland Linux is the most problematic, as the window transitions are not implemented correctly and it doesn't expose an event to indicate the window has been minimized, but I'm trying to do something about this. If having a bulletproof implementation is not required, the origin trials for all platforms at once seem to me like a better idea. As for Android freeform, I haven't yet tried it.

---

Correct, these are the tests to the feature. They are not very thorough - I couldn't find a way to create a standalone web application window/set web app scope using the web platform test (there's only a Chromium internal function internals.settings.setWebAppScope). They test whether the window methods and CSS properties are available and whether the methods return correct errors and CSS properties indicate the basic values. This is enough to tell there was a considerable effort put to implement the feature.

[patrykchodur]

I updated the spec to feature a requirement for the app to be an installed web application.

[michaelwasserman]

This is in decent shape, I just have a couple comments. Thanks for your patience.

[michaelwasserman]

lgtm with a heading update.
I also left some non-blocking thoughts for potential followup.

[michaelwasserman]

Not blocking, just a thought: This might deserve a note about the possible distinctions between browser window fullscreen and web content fullscreen (e.g. when a DOM element is fullscreen, vs when the browser window is made fullscreen).

[michaelwasserman]

Eventually, this should consider interactions between separate windows; e.g. windowA can call windowB = open('foo.html', '_blank', 'popup') and then call windowB.restore (from minimized) when the user clicks on windowA, so there might be two separate relevant global objects, and we'd want to consume transient activation from one while invoking the window display state change on another.