Same-screen presentation

[dlibby-]

I was curious if there has been any discussion of a use case for using the PresentationAPI to present to the same screen where the PresentationRequest originates. I tried searching through the issues, but was unable to find previous discussion.

PowerPoint online is evaluating using the PresentationAPI, and were interested in supporting slideshow 'presentation' (i.e. rehearsing) even when in single screen mode. They would also like to have a single unified codepath for handling this, rather than falling back to window.open/requestFullscreen. Additionally, cases such as mirrored single displays could also use this pattern of having one codepath that just uses the PresentationAPI.

As far as I can tell, there is nothing in the spec that disallows for this usage, but at the same time, given the goals of the spec, 'presenting' to the same screen certainly feels unintuitive. As far as I've seen, current implementations only display secondary displays as available choices for presentation requests.

[anssiko]

Thanks @dlibby-. That's a really good real-world use case and as you rightly pointed out the Presentation API spec does not disallow such usage: the presentation display can be any graphical and/or audio output device available to the user agent.

@mfoltzgoogle I vaguely recall you may have shared a UI mock or a prototype of such a picture-in-picture usage of Presentation API at some point, but I was unable to find a reference?

This usage would be similar to what Picture-in-Picture is for Remote Playback API, but for presenting any web content and not limited to video elements.

[dlibby-]

Thanks @anssiko - having a Picture-in-Picture surface sounds like a very interesting idea! However, I probably wasn't clear enough in my initial post as to what PowerPoint is trying to accomplish.

Today in PowerPoint's desktop application, if you click on the 'slide show' button in the bottom right corner, you will see the slides in fullscreen. If there is a second screen, the slides will be fullscreen on the second screen, and the original view will be changed to a notes view. If there is only one screen, the slides show up as fullscreen on the one screen, and the original view is not changed at all (though it is not visible unless you, e.g. alt-tab to switch back to it).

They are interested in supporting the latter case via PresentationAPI, but currently no user agent that I'm aware of will provide a choice of the current screen.

Based on your response, it sounds like this is not disallowed by the spec, so perhaps existing implementations could change to support this (would love to hear others' takes on this). Or perhaps we could consider adding an optional dictionary to PresentationRequest start() and getAvailability() to hint to the UA that this behavior is desired?

[anssiko]

@dlibby- thanks for the clarification. Let me try to rephrase the use case in terms of spec concepts (and please correct me if I got it wrong again :-)):

Mirror web content displayed on a presentation display to a Picture-in-Picture overlay on the controller page. (Optionally?) allow configuration of the size and location of the PiP overlay within the controller's viewport.

We discussed mirroring in https://github.com/w3c/presentation-api/issues/26 and back then alluded mirroring is not in scope, IIRC due to complexity of keeping the DOM state in sync across controller and presentation. I think we can revisit that topic given a good use case that I think we now have.

[tidoust]

@anssiko, I'll let @dlibby- respond but my understanding is that he is not talking about mirroring content at all, merely about being able to select the current screen as the presentation display in the selection menu that the user agent renders when PresentationRequest.start is called. Also, goal does not seem to be about creating a picture-in-picture window (or a separate tab), but rather to run the presentation in full screen.

In other words, it would be about allowing PresentationRequest.start to act as a local call to window.open followed by a call to requestFullscreen. I vaguely recall discussions about that but cannot find a pointer either. What I do remember is that we discussed the possibility for an application to add presentation displays that would be under its control to the selection menu (see #61). This was much more for cloud-based displays than to be able to reuse the current display, but perhaps that could be a useful direction to look at?

[markafoltz]

@dlibby I think I understand the use case but let me just ask a couple of clarifying questions:

1. If the user has both a primary display and secondary display, you would want the user to be able to choose either target to display the slides fullscreen from one button/icon. So it would make sense to have a picker with both "This display" and "Secondary monitor"?

2. If the user has only a primary display, can you just use requestFullscreen()? Or is it because you want an entirely separate browser window, and don't want the user to have to click once to open the window then a second time to make it fullscreen?

For #1, Chrome currently supports 1-UA mode to target presentations to attached wired displays, but we don't consider the "current" display to be a target. If we did, then presentation would be "available" 100% of the time, which could be unexpected from the user's point of view. In this scenario, if applications want this behavior it would make sense to add an option to the PresentationRequest to include the current display.

For #2, it could be possible to propagate user activation from window.open to requestFullscreen, but it feels very risky because you would be giving another origin full control over your desktop with a single click.

[dlibby-]

@anssiko - Yes, @tidoust has it correct. I should probably have specified that this is mainly geared toward 1-UA mode. And to clarify the mirroring I was referring to was OS-level mirroring (e.g. you connect to a projector and configure the display to mirror your single laptop screen and show that on the projector).

@mfoltzgoogle - For (1), I'll need to circle back to fully understand the use case, but I believe having both "This display" and "Secondary monitor" would potentially be ok. In any case, if there were an option on PresentationRequest start() , the application could be in control over what experience it provides. Thinking through this, PresentationRequest getAvailability() would indicate whether there are any secondary displays available. If the promise resolves with PresentationAvailability.value === false, (and remains false when monitoring onchange) the application could then peform a start() request that will allow the current display.

For (2), yes, requiring two clicks is the issue with requestFullscreen(). The application could be modified to perform requestFullscreen in the same document, but that would be a significant divergence from the PresentationAPI case where a new document is created and communicates with the original. I hadn't considered chaining user activation, but also am not clear whether this would be a good idea in practice, due to the risk you mentioned.

[anssiko]

@tidoust @mfoltzgoogle @dlibby- thanks for the clarifications. I think I finally get it.

If an option on PresentationRequest.start() (or some other backwards-compatible change) satisfies the requirement and there's implementer interest, we should turn this proposal into spec PR so we can review all the details. Also worth evaluating whether it makes sense to generalize the solution to address #61 (considering current implementer interest for cloud-paired screens, possible scope creep).

Now, I'll let you folks hash out the details of the API, and get out of the way :-)

[dlibby-]

Thanks folks - I'm circling back with PowerPoint to make sure the use case is adequately solved with the proposal. After which I'll create a PR and we can discuss further there. I'll keep in mind #61 as well (at a glance an optional dictionary seems flexible enough to at least enable the option)

[dlibby-]

I'm going to close this one out - Powerpoint has mentioned that they would be treating local vs. remote as different, so this doesn't appear to be a great fit for their use case at the moment.