Multi-Screen Window Placement on the Web - Initiating Multi-Screen Experiences

[michaelwasserman]

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

[michaelwasserman]

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

• A new Security Considerations section (and a terse Security and Privacy self-review)
  • These document and attempt to address points raised by earlier TAG review and Mozilla
• More detailed Spec Changes, with Multi-Screen Window Placement Working Draft Spec links.
• A new Example Code section

[torgo]

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?

[michaelwasserman]

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-management#98, w3c/window-management#92, w3c/window-management#74, and w3c/window-management#7.

[torgo]

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.

[torgo]

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

[michaelwasserman]

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

[torgo]

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.