+ajayrahatekar@ On Tuesday, February 15, 2022 at 8:27:55 AM UTC-8 ikilp...@chromium.org wrote:
> 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+...@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/6b305caf-d6e0-4f19-b0aa-68bb3cbf6ad9n%40chromium.org.
