Interoperability and Compatibility
Addition of a RuntimeEnabled 'change' EventHandler requires the existing Screen IDL interface to inherit EventTarget. Inheritance cannot currently be gated as a RuntimeEnabled feature; so we expect that inheritance change to have a minor effect on the stable JS API exposed to the web.
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.Edge
: No signal We'll request a position shortly, to give time for feedback before I2S. Edge has a related proposal for foldable devices: https://github.com/webscreens/window-segmentsWebKit
: 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.
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.
New dual-screen and foldable screen devices are entering the consumer market, increasing the complexity of exposing reliable and actionable screen information for all device form factors. Additionally, operating systems and their window managers support different levels of screen placement APIs, and new paradigms may emerge that complicate the availability of window placement features. See the Second Screen's "Form Factors Explained" report for more explorations on these topics: https://webscreens.github.io/form-factors/
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 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.
New and existing screen and window APIs are readily debuggable in existing developer tools.