Fullscreen Popup Windows

[bradtriebwasser]

こんにちは TAG-さん!

I'm requesting a TAG review of Fullscreen Popup Windows.

This proposal aims to reduce user and developer friction for initiating a fullscreen experience on the desired display of a multi-screen device. The proposed web platform enhancement allows web applications to open a new window in HTML fullscreen mode on a specific display with a single user gesture.

• Explainer: https://github.com/w3c/window-management/blob/main/EXPLAINER_fullscreen_popups.md
• User research: No additional research beyond the feature request (eg: 1) and this feature may be used as a basis for some other feature requests (2, 3)
• Security and Privacy self-review: https://github.com/w3c/window-management/blob/main/security_and_privacy_fullscreen_popups.md
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/window-management/issues
• Primary contacts (and their relationship to the specification):
  • [Author] Brad Triebwasser (@bradtriebwasser) - Google
  • [Contributor & author of original Window Management API] Mike Wasserman (@michaelwasserman) - Google
  • Joshua Bell (@inexorabletash), [Google] (Spec editor)
  • Anssi Kostiainen (@anssiko), [Intel] (Second Screen WG co-chair)
• Organization/project driving the design: Google Chrome
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/6002307972464640?context=myfeatures

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:
  • A design & discussion was discussed internally and is not publicly available. There is some additional public discussion in the feature request as well as the feature repository..
  • Mozilla Standard Position Request
  • Previous TAG Reviews on the Window Management API: Issue Multi-screen Window Placement features #522, Issue Early design review of the **updated** Multi-Screen Window Placement API #602, Issue Multi-Screen Window Placement on the Web - Initiating Multi-Screen Experiences #767
• Major unresolved issues with or opposition to this design: None
• This work is being funded by: Google Chrome

You should also know that...

This feature is mainly an extension to the features already shipped in the Window Management API (Issue #522, Issue #602, Issue #767). This feature adds an alternative & simplified method of creating a fullscreen popup and entering full screen on any display which is already possible with the API (which normally requires user activations). This feature reduces it to a single user activation.

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 [@bradtriebwasser]

---

[torgo]

Noting WebKit/standards-positions#101

[torgo]

Hi @bradtriebwasser thanks for sending us this. Some initial questions: is there any further info you can share on multi-stakeholder support, beyond the webkit and mozilla standards positions links - and secondly can you confirm if this draft reflects the consensus of the working group? Regarding the mitigation against the privacy / security issues, we're slightly concerned about prompt exhaustion, but that is a general concern that isn't unique to this review. Have you thought about any additional mitigation techniques?

[bradtriebwasser]

Hi @torgo,

Thanks for your feedback and apologies for the delay.

I requested Second Screen WG/CG feedback on the proposal and with permission, I moved the explainer into the WG repository. We plan to further discuss this proposal with the working group during TPAC 2023 (agenda). Additionally, please consider:

• The original request.
• Related requests (e.g. 1, 2, 3).
• A developer expressed support in repository issue Compositing and Blending Level 1 #2.
• We have partners already taking part in a dev trial, and we are actively soliciting their feedback, which has been positive thus far.

Prompt exhaustion is a valid concern, but security reviewers recommended gating this powerful feature by permission. Since targeting a specific screen implies window-management permission, re-using that permission avoids a separate prompt for this feature. Admins can alleviate enterprise users of this prompt, but that is a very narrow mitigation. We considered removing the window-management permission requirement for same-screen fullscreen popups, but the consensus was to gate all feature usage on permission for now. We generally support permission model innovation, but have not found a satisfying broad solution.
Note that since your review, I had also updated the explainer to consume a user gesture along with some other security considerations.

[hadleybeeman]

Hi @bradtriebwasser. We're just checking in on this. Where did you end up, in your quest for working group consensus? Is the Second Screen WG behind this proposal, or are you all still discussing?

[anssiko]

@hadleybeeman let me try to provide the latest status, @bradtriebwasser will fill me in as needed. Most recently the Second Screen WG discussed this proposal during TPAC 2023 F2F.

In fact, the WG discussed a number of new proposed extensions to the Window Management API, this is one of them. The aim was not to try to establish a consensus position at this stage but familiarize the group with what is proposed. The WG is looking forward to Origin Trial feedback that will help inform the WG.

[hadleybeeman]

Thanks for the reply, @anssiko. Are there alternative proposals for similar functionality that the WG is also considering? Is there is a particular architectural question we can help with, or are you having trouble achieving consensus in a way that we can help with?

At this stage, we would recommend that, as a working group, you all work towards consensus and come back to us when you have a single proposal for us to review.

Having said all that, we have looked at what you are proposing here and are recording a couple of thoughts as well.

We noticed that there isn't specific mention of focus management or accessibility in the explainer. Can you make accessibility considerations explicit in the explainer / spec?

Another specific question that came up in our discussion: do you require passing in 4 coordinates of the other screen when targeting a different screen? Passing a screen's label may have better developer ergonomics.

Considering the early stage here, we don't think it's appropriate to give a final review on this proposal at this time. You can re-open the issue if you have any specific questions, or feel free to open a new issue with broader architectural concerns.

[anssiko]

Thanks for your thoughts and guidance for this early design review request. The explainer documents other alternatives considered and brought to the WG's attention. All these alternatives have shortcomings as documented in the explainer, a motivator for this new proposal.

Your ask regarding a11y and suggestion for better developer ergonomics are well received and will be considered.

As said, the WG will listen to Origin Trial feedback and will come back should the feedback suggest there is significant user need for this feature among early adopter population. Thank you for your time and guidance.

[hadleybeeman]

Great, thanks @anssiko! We will close this issue then.

Feel free to get back in touch when the working group has chosen a way forward, if we can help at that point.