Hi All, Due to the new Chrome 4 week cycle release cycle and the team expecting to land so CLs during the OT, can we please have approval to extend the OT by one milestone to M96? The new OT window would be M93-M96
Thanks in advance, Ajay On Thursday, July 1, 2021 at 12:34:21 PM UTC-7 Mike West wrote: > LGTM to experiment from M93-M95. > > Good luck! > > -mike > > > On Thu, Jul 1, 2021 at 9:30 PM Mike Wasserman <m...@google.com> wrote: > >> Thanks Mike and Yoav, >> >> Yes, M93-M95 is our target timeframe for this second OT. >> As Tom said, we made nontrivial API shape (and implementation) changes to >> address feedback from the first OT. >> See CHANGES.md >> <https://github.com/webscreens/window-placement/blob/main/CHANGES.md>, the >> spec PR <https://github.com/GoogleChrome/web.dev/pull/5591>, a slide >> <https://docs.google.com/presentation/d/1to93_cM_k81G0Fd1tLwu3b5nTfg3J8L6p-QOJqqahn4/edit#slide=id.g9cfde39f64_1_14> >> (some >> of that deck is outdated), and a google-internal (for now) shape change >> <https://docs.google.com/document/d/1lgCentReLlym6j9kBS_Qo3r2HHZ6Ov7cSGjSWyi8cYs> >> design >> doc. >> We want to ensure these changes satisfy partner needs and work well >> across a variety of OS+display configuration environments. >> >> Let me know if you have any questions or requests. Thanks! >> Mike >> >> On Thu, Jul 1, 2021 at 11:36 AM Mike West <mk...@chromium.org> wrote: >> >>> I appreciate the work y'all have done to satisfy folks from the security >>> and privacy teams around the UX of this feature. I'm comfortable with y'all >>> taking another stab at getting feedback from developers. >>> >>> What timeline are you requesting for experimentation? M93-M95ish? >>> >>> -mike >>> >>> >>> On Tue, Jun 29, 2021 at 10:29 AM 'Thomas Steiner' via blink-dev < >>> blin...@chromium.org> wrote: >>> >>>> Hi Yoav, >>>> >>>> The API changes are documented in >>>> https://github.com/webscreens/window-placement/blob/main/CHANGES.md >>>> (and https://github.com/GoogleChrome/web.dev/pull/5591). The tl;dr is >>>> that the API shape and ergonomics have changed, based on the feedback from >>>> the first origin trial. >>>> >>>> Cheers, >>>> Tom >>>> >>>> >>>> On Mon, Jun 28, 2021 at 5:48 PM Yoav Weiss <yoav...@chromium.org> >>>> wrote: >>>> >>>>> Thanks for working on a better multi-screen experience! I know I could >>>>> use that as a user :) >>>>> >>>>> What's the relationship between this and the previous I2E >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/C6xw8i1ZIdE>? >>>>> Has the API changed since? Any learnings from the previous trial that >>>>> were >>>>> incorporated into the current design? >>>>> >>>>> On Fri, Jun 25, 2021 at 10:49 PM 'Mike Wasserman' via blink-dev < >>>>> blin...@chromium.org> wrote: >>>>> >>>>>> Contact emailsm...@chromium.org, en...@chromium.org >>>>>> >>>>>> Explainerhttps://github.com/webscreens/window-placement >>>>>> >>>>>> Specificationhttps://webscreens.github.io/window-placement/ >>>>>> >>>>>> Design docshttps://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 componentUI>Browser>WebAppInstalls >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3EWebAppInstalls> >>>>>> >>>>>> Search tagswindow placement >>>>>> <https://www.chromestatus.com/features#tags:window%20placement>, screen >>>>>> enumeration >>>>>> <https://www.chromestatus.com/features#tags:screen%20enumeration>, >>>>>> window <https://www.chromestatus.com/features#tags:window>, open >>>>>> <https://www.chromestatus.com/features#tags:open>, moveTo >>>>>> <https://www.chromestatus.com/features#tags:moveTo>, moveBy >>>>>> <https://www.chromestatus.com/features#tags:moveBy>, >>>>>> requestFullscreen >>>>>> <https://www.chromestatus.com/features#tags:requestFullscreen>, >>>>>> screen <https://www.chromestatus.com/features#tags:screen>, display >>>>>> <https://www.chromestatus.com/features#tags:display>, monitor >>>>>> <https://www.chromestatus.com/features#tags:monitor>, multi-screen >>>>>> <https://www.chromestatus.com/features#tags:multi-screen>, >>>>>> multi-display >>>>>> <https://www.chromestatus.com/features#tags:multi-display>, >>>>>> multi-monitor >>>>>> <https://www.chromestatus.com/features#tags:multi-monitor>, >>>>>> cross-screen >>>>>> <https://www.chromestatus.com/features#tags:cross-screen>, >>>>>> cross-display >>>>>> <https://www.chromestatus.com/features#tags:cross-display>, >>>>>> cross-monitor >>>>>> <https://www.chromestatus.com/features#tags:cross-monitor> >>>>>> >>>>>> TAG reviewhttps://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 statusPending >>>>>> >>>>>> 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/ The Screen IDL interface >>>>>> duplicates EventTarget members to mark them RuntimeEnabled for this >>>>>> experiment, since using interface inheritance would also change the >>>>>> stable >>>>>> JS API. >>>>>> >>>>>> >>>>>> Gecko: No signal We requested a position and are waiting for >>>>>> feedback. https://github.com/mozilla/standards-positions/issues/542 >>>>>> Firefox >>>>>> supports cross-screen window.open/move*() requests. This work partly >>>>>> pursues compatibility with that behavior. >>>>>> >>>>>> WebKit: No signal We requested a position and are waiting for >>>>>> feedback. >>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031903.html >>>>>> >>>>>> Web developers: Positive ( >>>>>> https://github.com/webscreens/window-placement/issues) Positive. >>>>>> This work is also of interest to Google Slides. See: >>>>>> https://discourse.wicg.io/t/proposal-supporting-window-placement-on-multi-screen-devices >>>>>> See: https://github.com/webscreens/window-placement/issues >>>>>> >>>>>> 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 have some minor potential ergonomics issues around >>>>>> naming, >>>>>> object comparison, and event handling that we hope to resolve using OT >>>>>> feedback. See https://github.com/webscreens/window-placement/issues >>>>>> for more details. 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/ >>>>>> >>>>>> >>>>>> 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, 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, a permissions policy, >>>>>> 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. The API shape has changed significantly since the first >>>>>> Origin Trial (M86-M88), and we would like to get additional developer >>>>>> feedback before shipping. - 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. >>>>>> >>>>>> >>>>>> Reason this experiment is being extended >>>>>> >>>>>> N/A >>>>>> >>>>>> >>>>>> 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 >>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>> ?No >>>>>> >>>>>> Flag name--enable-blink-features=WindowPlacement >>>>>> >>>>>> Tracking bug >>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=897300 >>>>>> >>>>>> Launch bug >>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1169426 >>>>>> >>>>>> Measurement >>>>>> https://chromestatus.com/metrics/feature/popularity#V8Window_GetScreens_Method >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://www.chromestatus.com/feature/5252960583942144 >>>>>> >>>>>> Links to previous Intent discussionsIntent to prototype: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/X6rEbWvU7cI >>>>>> Intent to Experiment: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/C6xw8i1ZIdE >>>>>> >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://www.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/CAEsbcpV_s7jHYVhdGaxiG83w0VVi1k-ze8apqL5aqD%2BSawnpGg%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpV_s7jHYVhdGaxiG83w0VVi1k-ze8apqL5aqD%2BSawnpGg%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+...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXRdkfHdDBEJ5MgeCzQbahOrbmJC3N4pCFA__Sw3Aem9A%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXRdkfHdDBEJ5MgeCzQbahOrbmJC3N4pCFA__Sw3Aem9A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, >>>> https://twitter.com/tomayac) >>>> >>>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany >>>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.1.23 (GNU/Linux) >>>> >>>> >>>> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. >>>> hTtPs://xKcd.cOm/1181/ >>>> -----END PGP SIGNATURE----- >>>> >>>> -- >>>> 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/CALgRrL%3Dnra3ZG9D4BgNz6Okye3qfcFpc6DS2FFRVZ%2BrchGWDag%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrL%3Dnra3ZG9D4BgNz6Okye3qfcFpc6DS2FFRVZ%2BrchGWDag%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/3a08c6c0-7fce-42b0-bbd9-b910f1c9dc46n%40chromium.org.
