Intent to Ship: Multi-Screen Window Placement

253 views
Skip to first unread message

Michael Wasserman

unread,
Feb 14, 2022, 8:28:55 PMFeb 14
to blink-dev

Contact emails

m...@chromium.org


Explainer

https://github.com/webscreens/window-placement


Specification

https://webscreens.github.io/window-placement/


Design docs 

https://web.dev/multi-screen-window-placement/


Summary

Adds new screen information APIs and makes incremental improvements to existing window placement APIs, allowing web applications to offer compelling multi-screen experiences.


The existing singular window.screen offers a limited view of available screen space, and window placement functions generally clamp bounds to the current screen. This feature unlocks modern multi-screen workspaces for web applications.


Blink component

UI>Browser>WebAppInstalls>Desktop


Search tags

window placement, screen enumeration, window, open, moveTo, moveBy, requestFullscreen, screen, display, monitor, multi-screen, multi-display, multi-monitor, cross-screen, cross-display, cross-monitor


TAG review

https://github.com/w3ctag/design-reviews/issues/413 https://github.com/w3ctag/design-reviews/issues/522 https://github.com/w3ctag/design-reviews/issues/602


TAG review status

Issues addressed


Risks


Interoperability and Compatibility

Feature detection of new screen information APIs and Permission API integration allows sites to handle different levels of feature support. The Screen IDL interface duplicates EventTarget members for RuntimeEnabled experimentation without changing the stable JS API; this will be rectified after launch approval.


Existing window placement APIs generally use compatible multi-screen coordinates, but implementations often restrict bounds to the current screen. We expect low levels of risk in supporting permitted cross-screen placement requests, and falling back on legacy same-screen behavior otherwise.


A detailed assessment of API design risks, including Wayland compatibility, multiple virtual workspaces/desktops, and more, can be found at: <https://docs.google.com/document/d/19u5fRKs8iWlpecKBSlfQ6JKrcP4emwK0M_6TNhfz0gs>


API surface changes made during the second origin trial are limited to some minor renames, the removal of two unimplemented screen properties, and support for permission policy. An exploratory permission-gated capability to swap the screen of fullscreen windows without a user gesture was reverted to enhance usable security. See <https://github.com/webscreens/window-placement/blob/main/CHANGES.md>


The spec is being incubated in the W3C Second Screen CG <https://webscreens.github.io/cg-charter> and is pending adoption by the W3C Second Screen WG <https://w3c.github.io/secondscreen-charter>


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/542) We requested a position and are waiting for feedback. Firefox supports cross-screen window.open/move*() requests. This work partly pursues compatibility with that behavior.


WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031903.html) We requested a position and are waiting for feedback.


Web developers: Positive (https://github.com/webscreens/window-placement/issues/67)

- Discourse: <https://discourse.wicg.io/t/proposal-supporting-window-placement-on-multi-screen-devices>

- Twitter: <https://twitter.com/search?q=url%3Amulti-screen-window-placement&src=typed_query&f=live>

- Announcement: <https://twitter.com/ChromiumDev/status/1305406689466814464>

- HackerNews (was front page): <https://news.ycombinator.com/item?id=24489234>

- Citrix: <https://github.com/webscreens/window-placement/issues/67#issuecomment-945859384>

- This work is also of interest to Google Slides


Ergonomics

The minor improvements to window.open/move*() API behaviors have no effect on their poor ergonomics (synchronous, features string shape, etc.). This API does not preclude future work from improving the ergonomics of those existing APIs. Extending the requestFullscreen dictionary with an optional screen should pose no ergonomic risks. The new multi-screen information APIs incorporated OT feedback to improve naming, object comparison, and event handling ergonomics.


Activation

This feature incrementally extends existing screen information and window placement interfaces with basic multi-screen support. This immediately enables new compelling experiences through progressive enhancement of existing applications.


Security

Security and Privacy risks are explored in the specification repository’s W3C Questionnaire <https://github.com/webscreens/window-placement/blob/main/security_and_privacy.md>, and in the respective sections of the draft specification <https://webscreens.github.io/window-placement/#security> and <https://webscreens.github.io/window-placement/#privacy>. That analysis and review uncovered minimal risks.


Privacy concerns center around fingerprinting screen information, while security risks center around deceptive, surreptitious, or annoying window placements, such as clickjacking. Gating new functionality with a permission helps mitigate these concerns, and may aid or inspire similar protections for legacy API behavior with similar abuse vectors. The overall added risks are low and further mitigated by limiting to secure contexts, supporting a permissions policy, being selective about display information to expose, and continuing to prevent off-screen window placement.


Origin trial feedback

  • First origin trial: Developer feedback (Google-internal doc) was generally straightforward: the API is useful, and it would be difficult or impossible to accomplish anything similar without it. The most common request was that it be made broadly available as soon as possible. There were two feature requests; and while neither is provided with this initial launch, the API shape does not preclude adding support:

    • to hide the location bar on popup windows

    • for getScreens() to return information about mirrored displays



  • Second origin trial: Once again, developer feedback (Google-internal doc) was broadly positive. One feature was requested three times: the ability to open a new window and immediately make it fullscreen. This feature is on our roadmap. Demand for this API is high, and we want to give developers the chance to start using it as soon as possible. Thus it makes sense to launch an MVP, then add additional features like this one.


Debuggability

New and existing screen and window APIs are readily debuggable using the developer tools console.


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

WPTs cover the presence of new JS APIs and some basic API functionality: <https://wpt.fyi/results/screen-details>, <https://wpt.live/window-placement>, and <https://wpt.fyi/results/fullscreen/api/element-request-fullscreen-options.tentative.html>. We aim to extend test coverage and support for multi-screen mocking <https://crbug.com/1252062> and cross-screen window placement tests <https://crbug.com/1022988> soon.


Flag name

chrome://flags#enable-experimental-web-platform-features enables the WindowPlacement RuntimeEnabled feature flag (--enable-blink-features=WindowPlacement)


Requires code in //chrome?

Not really - Some relevant test, permission, and pre-existing windowing code lives in //chrome.


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=897300


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1255960


Measurement

https://chromestatus.com/metrics/feature/popularity#V8Window_GetScreenDetails_Method


Sample links

https://michaelwasserman.github.io/window-placement-demo/

https://web.dev/multi-screen-window-placement/#demo


Estimated milestones

OriginTrial desktop last

96

OriginTrial desktop first

93

DevTrial on desktop

93


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5252960583942144


Links to previous Intent discussions

Intent to Prototype: <https://groups.google.com/a/chromium.org/g/blink-dev/c/X6rEbWvU7cI>

Intent to Experiment: (OT1) <https://groups.google.com/a/chromium.org/g/blink-dev/c/C6xw8i1ZIdE>

Intent to Experiment: (OT2) <https://groups.google.com/a/chromium.org/g/blink-dev/c/jznxQK1U8ZQ>


This intent message was generated by Chrome Platform Status.

Ian Kilpatrick

unread,
Feb 15, 2022, 11:27:55 AMFeb 15
to Michael Wasserman, blink-dev
On Mon, Feb 14, 2022 at 5:28 PM Michael Wasserman <m...@chromium.org> wrote:

Contact emails

m...@chromium.org


Explainer

https://github.com/webscreens/window-placement


Specification

https://webscreens.github.io/window-placement/


Design docs 

https://web.dev/multi-screen-window-placement/


Summary

Adds new screen information APIs and makes incremental improvements to existing window placement APIs, allowing web applications to offer compelling multi-screen experiences.


The existing singular window.screen offers a limited view of available screen space, and window placement functions generally clamp bounds to the current screen. This feature unlocks modern multi-screen workspaces for web applications.


Blink component

UI>Browser>WebAppInstalls>Desktop



This isn't a great component for code that lives within Blink. Can we create a new component for anything screen API related with the team working on this responsible for triaging these bugs?

E.g. something like Blink>Screen or Blink>ScreenAPIs

Specifically any code that lives within Blink should have a Blink component due to how top level triage works.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpUThcD2OSgoebUZuXSevjwBGV0r8Kw3SDrCXGjtB6kx-w%40mail.gmail.com.

Ajay Rahatekar

unread,
Feb 16, 2022, 11:26:20 AMFeb 16
to blink-dev, ikilp...@chromium.org, blink-dev, Mike Wasserman
+ajayrahatekar@

Mike Wasserman

unread,
Feb 16, 2022, 2:20:08 PMFeb 16
to Ben Morss, blink-dev, Ajay Rahatekar, ikilp...@chromium.org
Thank you for the suggestion. I filed a component request at crbug.com/1298140 [RVG] and I'll follow up here when there is a resolution.

On Wed, Feb 16, 2022 at 9:31 AM Ben Morss <mo...@google.com> wrote:
+morss@ as well

Ben Morss

unread,
Feb 17, 2022, 11:56:01 PMFeb 17
to blink-dev, Ajay Rahatekar, ikilp...@chromium.org, blink-dev, Mike Wasserman
+morss@ as well

On Wednesday, February 16, 2022 at 11:26:20 AM UTC-5 Ajay Rahatekar wrote:

Mike Taylor

unread,
Feb 18, 2022, 10:28:50 AMFeb 18
to Michael Wasserman, blink-dev
Hi Michael,

I think you and team have done a great job incorporating TAG and API ergonomics feedback (hi Jake!) as well as privacy concerns. Nice work.

LGTM1.
(I was intrigued to see Positive feedback coming from HackerNews, but we should probably consider that to be Negative.)
--

Ajay Rahatekar

unread,
Feb 22, 2022, 3:37:12 PMFeb 22
to blink-dev, mike...@chromium.org, blink-dev, Mike Wasserman
Hello Blink APi owners,

Please let us know if you need more details. The team is targeting shipping the API in M100 and would be very appreciative of early feedback/approval to meet the milestone timeline requirements.

Thanks in advance.

Ajay

Yoav Weiss

unread,
Feb 23, 2022, 8:07:39 AMFeb 23
to Ajay Rahatekar, blink-dev, mike...@chromium.org, Mike Wasserman
LGTM2

This seems like an important use-case to tackle!

On Tue, Feb 22, 2022 at 9:37 PM 'Ajay Rahatekar' via blink-dev <blin...@chromium.org> wrote:
Hello Blink APi owners,

Please let us know if you need more details. The team is targeting shipping the API in M100 and would be very appreciative of early feedback/approval to meet the milestone timeline requirements.

Thanks in advance.

Ajay

On Friday, February 18, 2022 at 7:28:50 AM UTC-8 mike...@chromium.org wrote:
Hi Michael,

I think you and team have done a great job incorporating TAG and API ergonomics feedback (hi Jake!) as well as privacy concerns. Nice work.

LGTM1.

On 2/14/22 8:28 PM, Michael Wasserman wrote:

Great explainer! Thanks for that!! 

Mike West

unread,
Feb 23, 2022, 8:57:57 AMFeb 23
to Yoav Weiss, Illia Klimov, Balazs Engedy, Ajay Rahatekar, blink-dev, mike...@chromium.org, Mike Wasserman
LGTM3. Thanks for the work y'all have done with the security and privacy teams to get this in the right place. I believe permissions folks want to follow up about the shape of the final implementation from a UX perspective, so please ensure that you chat with +Illia Klimov and/or +Balazs Engedy before flipping the flags, but I think you're good to go from a web platform perspective.

Thanks!

-mike


Ben Morss

unread,
Feb 23, 2022, 10:44:38 AMFeb 23
to blink-dev, mk...@chromium.org, Ajay Rahatekar, blink-dev, mike...@chromium.org, Mike Wasserman, yoav...@chromium.org, Illia Klimov, Balazs Engedy
Thanks for weighing in, everyone. Glad to see these approvals coming in!

Ben
Reply all
Reply to author
Forward
0 new messages