#767: Multi-Screen Window Placement on the Web - Initiating Multi-Screen Experiences

Visit on Github.

Opened Aug 31, 2022

Wotcher TAG!

I'm requesting a TAG review of Multi-Screen Window Placement on the Web - Initiating Multi-Screen Experiences.

This proposal introduces a Multi-Screen Window Placement API enhancement that would allow web applications to initiate a multi-screen experience from a single user activation.

  • Explainer¹ (minimally containing user needs and example code): Explainer
  • User research: Feature Request
  • Security and Privacy self-review²: Questionnaire
  • GitHub repo (if you prefer feedback filed there): Repo
  • Primary contacts (and their relationship to the specification):
    • Mike Wasserman (@michaelwasserman), [Google] (Spec editor)
    • Joshua Bell (@inexorabletash), [Google] (Spec editor)
    • Anssi Kostiainen (@anssiko), [Intel] (Second Screen WG co-chair)
    • Louay Bassbouss (@louaybassbouss), [Fraunhofer FOKUS] (Second Screen WG co-chair)
  • Organization/project driving the design: Google
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5173162437246976

Further details:

  • [✓] I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): Second Screen WG
  • The group where standardization of this work is intended to be done ("unknown" if not known): Second Screen WG
  • Existing major pieces of multi-stakeholder review or discussion of this design: Mozilla standards position issue and Prior TAG review request
  • Major unresolved issues with or opposition to this design: Mozilla security considerations (see above), TAG request for a new design review (see above)
  • This work is being funded by: Google

You should also know that...

I appreciate your time reviewing this proposal; thank you!

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @michaelwasserman

Discussions

Comment by @michaelwasserman Aug 31, 2022 (See Github)

If it is helpful, the high-level Explainer changes since my earlier review request are:

Discussed Oct 1, 2022 (See Github)

Dan: I note it's shipping in Chrome 104.

Dan: the work they've done addresses concerns that were raised by the TAG previously...

Discussed Oct 1, 2022 (See Github)

Dan: two weeks ago we asked for information, they said it shouldn't have been marked as early but they appreciate TAG feedback including [specific question].

Comment by @torgo Oct 19, 2022 (See Github)

Hi @michaelwasserman the chrome status for this says shipped in 104. Does that mean it's shipping or is it behind a flag? Also in what sense is the review request an early review? We've been a little slow on the uptake on this one - and sorry for that - but can you give us an update on the current status, also with regard to additional stakeholders / engines that are supporting?

Comment by @michaelwasserman Oct 19, 2022 (See Github)

This is available in Chrome without a flag since 104. A partner requested this functionality when integrating the Multi-Screen Window Placement API in their web application. We have not yet received explicit signals from any other engines. Should I have requested a "Specification review" rather than an "Early design review"?

I would still greatly appreciate TAG feedback, and especially guidance for generalizing the design to support initiating a broader set of multi-display web application experiences. Web application developers have continued to express strong interest in this space via w3c/window-placement#98, w3c/window-placement#92, w3c/window-placement#74, and w3c/window-placement#7.

Discussed Nov 1, 2022 (See Github)

Dan: shipping, early, no signals from other engines

Amy: A couple of still-open moz standards positions 636 and 542... not closed, lots of back and forth about security issues, not looking great on surface-level analysis.

Dan: "There is no obvious way for a web application to detect support for the proposed feature." Doesn't sound great.

Rossen: what does it mean for the primary contact to be the incubation group?

Amy: Also looks like there was a conversation at TPAC...

Rossen: One thing: how would I map parts of the elements' subtree - hello world e.g. centered inisde of the element. How would a screen reader get the relative coordinates of that element in respect to the screen reader? In order for the screen reader to draw its focus rectangle it would need to know where the element is. That location is usually relative to the window... since AT API allows you to keep traversing up to the screen you will know you're relative to a screen but if you're part of a document how would you know you're relative to a different screen. I get how it works with multi-windows - but in here you have essentially one window.

<blockquote> Hi @michaelwasserman yes probably it would have been better to request a spec review for something this far along in the process. We're concerned about the lack of multi-stakeholder support or signals thereof. We note extensive discussion on the security considerations in mozilla/standards-positions [#636](https://github.com/mozilla/standards-positions/issues/636) and [#542](https://github.com/mozilla/standards-positions/issues/542) which don't seem to have come to resolution yet. Any update on this or info on other implementers supporting / working on this? Lack of feature detection is also concerning and goes against our [design principle](https://w3ctag.github.io/design-principles/#feature-detect) on detectability. </blockquote>

posted

Comment by @torgo Nov 28, 2022 (See Github)

Hi @michaelwasserman yes probably it would have been better to request a spec review for something this far along in the process. We're concerned about the lack of multi-stakeholder support or signals thereof. We note extensive discussion on the security considerations in mozilla/standards-positions #636 and #542 which don't seem to have come to resolution yet. Any update on this or info on other implementers supporting / working on this? Lack of feature detection is also concerning and goes against our design principle on detectability.

Discussed Feb 1, 2023 (See Github)

Max: no feedback yet.

Comment by @torgo Feb 28, 2023 (See Github)

Hi @michaelwasserman has there been any update you can share? Thanks!

Discussed Mar 1, 2023 (See Github)

Dan: michael responded to our request and has indicated many things being worked on - responsive to TAG feedback.

Hi @michaelwasserman I see your virtual meeting happened yesterday - sorry we didn't get you feedback prior to that.  Based on your comments it looks like the issues TAG has raised are being considered.  On this basis we're happy to close this review as "satisfied".  

Regarding opening up a new review request for the entire spec, I think we already had some signifigant discussion in [issue 602](https://github.com/w3ctag/design-reviews/issues/602).  I think it may be appropriate to open up a new issue as part of wide review when the spec goes to CR.
Comment by @michaelwasserman Mar 2, 2023 (See Github)

Hi @torgo, thanks for your consideration and persistence, I apologize for my delayed reply.

  1. Regarding Mozilla standards positions (#636 and #542): We held promising discussions in webscreens 2022 Q2 and TPAC 2022 meetings. I also merged #100 and replied with security consideration clarifications and new mitigation ideas. We are still awaiting a response.

  2. Regarding WebKit's standards positions: We are awaiting responses on #117 and older webkit-dev requests (original api and this enhancement), and other forms of outreach have not yet been fruitful.

  3. There is a spec issue for feature-detection, which deserves exploration and discussion.

Here are some AIs I can take upon myself, WDYT?

  • Open a new TAG spec review request (for the entire spec) as part of our wide review effort.
  • Ping and update standards-positions issues and invite discussion before/during Second Screen WG/CG - 2023 Q1 virtual meeting #7
  • Continue refining the spec’s security considerations section and feature-detection issue
Comment by @torgo Mar 23, 2023 (See Github)

Hi @michaelwasserman Based on your comments it looks like the issues TAG has raised are being considered. On this basis we’re happy to close this review as “satisfied with concerns” - the concerns being the lack of multi-stakeholder support.

Regarding opening up a new review request for the entire spec, I think we already had some significant discussion in issue 602. I think it may be appropriate to open up a new issue as part of wide review when the spec goes to CR.