Intent to Ship: Multi-Screen Window Placement
Michael Wasserman
Contact emails
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
Feedback on Github: After the OT, @jakearchibald, @kenchris, and others gave feedback on the API shape <https://github.com/webscreens/window-placement/issues/30>. Changes were made accordingly <https://github.com/webscreens/window-placement/blob/main/CHANGES.md>.
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
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
Contact emails
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
--
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
Mike Wasserman
+morss@ as well
Ben Morss
Mike Taylor
--
Ajay Rahatekar
Yoav Weiss
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.AjayOn 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:
Contact emails
Explainer
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c9f9bfc3-863c-487b-9cfb-b7fd3b0aa6ecn%40chromium.org.
Mike West
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWYap_kr1OYWoLVm81Mxf2nDYOux6dKd3_5RqVTuMfnMQ%40mail.gmail.com.