Intent to Experiment: Cross-Screen Window Placement

165 views
Skip to first unread message

Michael Wasserman

unread,
Aug 19, 2020, 3:05:05 PM8/19/20
to blin...@chromium.org

Contact emails

m...@chromium.org


Explainer

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


TAG review

https://github.com/w3ctag/design-reviews/issues/413 (Screen Enumeration)

https://github.com/w3ctag/design-reviews/issues/522 (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.


Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/LDymWZeV7jo (Screen Enumeration)

https://groups.google.com/a/chromium.org/g/blink-dev/c/SFyBx9MrGRo (Window Placement)


Risks


Interoperability and Compatibility

Feature detection of new screen information APIs and Permission API integration allows sites to handle different levels of feature support.


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.


This work is included in the W3C Second Screen CG charter to seek consensus and support for broad interoperability: https://webscreens.github.io/cg-charter/


Gecko: No signal - We'll request a position shortly, to give time for feedback before I2S. Firefox supports cross-screen window.open/move*() requests. This work partly pursues compatibility with that behavior.


WebKit: No signal - We'll request a position shortly, to give time for feedback before I2S.


Web developers: Positive (https://github.com/webscreens/window-placement/issues) This work is of interest to GSuite / Google Slides.


Ergonomics

New asynchronous screen information APIs serve static dictionary snapshots of device configurations shaped similar to (but slightly more ergonomic than) the existing Screen interface, which offers synchronous access to a singular window.screen live object.


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.


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 repo documents: <https://github.com/webscreens/window-placement>. 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. 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, providing origin-scoped generated screen ids that reset when cookies are cleared, being selective about display information to expose, and continuing to prevent off-screen window placement.


Goals for experimentation

We want developer feedback around the feature's performance and applicability in production scenarios with a broad set of screen configurations.

  • Does the feature permit sufficiently expressive placement requests?

  • Does the permission model/flow integrate well with product design?

  • Do any screen configurations or placement scenarios pose unforeseen challenges?

At least one major customer inside Google wants to use this API in their product. We want to learn from their deployment experiences and collect metrics on feature subsets.


Experimental timeline

M86-M88


Ongoing technical constraints

None.


Debuggability

New and existing screen and window APIs are readily debuggable in existing developer tools.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No - All Blink platforms have some support for multiple displays, but may restrict the placement and sizing of windows. The overall API will be exposed everywhere except WebView, as developers have primarily voiced interest for use cases in desktop applications, and the added complexity strongly exceeds developer enthusiasm for WebView support. All other Blink platforms will be supported.


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

No - WPTs cover the presence of new JS APIs and some basic functionality: <https://wpt.fyi/results/screen_enumeration>. We aim to extend test coverage for cross-screen window placements, but existing coverage and support for multi-screen and window placement tests is extremely limited. See https://crbug.com/1075656 and https://crbug.com/1022988 for details.


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5252960583942144


Chris Harrelson

unread,
Aug 19, 2020, 9:25:15 PM8/19/20
to Michael Wasserman, blink-dev
On Wed, Aug 19, 2020 at 12:05 PM Michael Wasserman <m...@chromium.org> wrote:

Do you have a draft spec as well? 
--
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/CAEsbcpUg_%3DQ5A4aYmWs40v4B7R%2BW%3D_J3Tc6SKeOke8Z6%3DWDedQ%40mail.gmail.com.

Michael Wasserman

unread,
Aug 25, 2020, 5:01:44 PM8/25/20
to Chris Harrelson, blink-dev
We just started iterating on a draft spec; thanks for your patience!

The explainer provides adequate details for developers participating in the Origin Trial, and less formal explanations of proposed fullscreen and cssom-view spec changes. We're actively formalizing and moving that content to draft spec.

Chris Harrelson

unread,
Aug 25, 2020, 6:00:07 PM8/25/20
to Michael Wasserman, blink-dev
Reply all
Reply to author
Forward
0 new messages