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 > <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3EWebAppInstalls%3EDesktop> > > 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. Search tags > > window placement > <https://chromestatus.com/features#tags:window%20placement>, screen > enumeration <https://chromestatus.com/features#tags:screen%20enumeration>, > window <https://chromestatus.com/features#tags:window>, open > <https://chromestatus.com/features#tags:open>, moveTo > <https://chromestatus.com/features#tags:moveTo>, moveBy > <https://chromestatus.com/features#tags:moveBy>, requestFullscreen > <https://chromestatus.com/features#tags:requestFullscreen>, screen > <https://chromestatus.com/features#tags:screen>, display > <https://chromestatus.com/features#tags:display>, monitor > <https://chromestatus.com/features#tags:monitor>, multi-screen > <https://chromestatus.com/features#tags:multi-screen>, multi-display > <https://chromestatus.com/features#tags:multi-display>, multi-monitor > <https://chromestatus.com/features#tags:multi-monitor>, cross-screen > <https://chromestatus.com/features#tags:cross-screen>, cross-display > <https://chromestatus.com/features#tags:cross-display>, cross-monitor > <https://chromestatus.com/features#tags: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 > > <https://docs.google.com/spreadsheets/d/1S66d7izby2_QNu1FqLY_tEpQA9xkAsruvam7nbsq2TI/edit?resourcekey=0-kfJ0PdgNU5wgmjGWJc8AGg#gid=727492058> > (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 > > <https://docs.google.com/spreadsheets/d/1S66d7izby2_QNu1FqLY_tEpQA9xkAsruvam7nbsq2TI/edit?resourcekey=0-kfJ0PdgNU5wgmjGWJc8AGg#gid=1625618615> > (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 > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? > > 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 > <https://chromestatus.com/>. > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpUThcD2OSgoebUZuXSevjwBGV0r8Kw3SDrCXGjtB6kx-w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpQAzERT9rpCw2PN2ciFOQM9ZHmniuR5qVzG3WpEO8tc%3DQ%40mail.gmail.com.
