Add support for allowing same-screen display

[dlibby-]

Addresses #476.
Add an options dictionary to PresentationRequest.start() that indicates the list of available displays that the user can choose from must include the current display.

I thought about plumbing this through to "monitor the list of available presentation displays", but this won't ever be used for getAvailability() and it wasn't clear to me how to mechanically do this in the spec (all ears if there are suggestions though!).

Once there's some consensus that this is the right approach, I'll work on adding a WPT and reference it in this PR description.

---

Preview | Diff

[anssiko]

Thanks! @mfoltzgoogle to advise on your second option to plumb this through https://w3c.github.io/presentation-api/#monitoring-the-list-of-available-presentation-displays

[dlibby-]

ping @mfoltzgoogle - can you take a look? Thanks!

[dlibby-]

@mfoltzgoogle - can you take a look when you get a chance?

[takumif]

FYI Mark is unavailable until next Monday.

[mfoltzgoogle]

@dlibby- Sorry for the very delayed response, I was unable to spend much time on SSWG issues until recently.

If I understand correctly, the desire is to use the Presentation API to open a new browser window and have it possibly shown on the current display, or a local secondary display or remote display (which are all the possible scenarios I can think of).

If the user chooses the current display, were you assuming that the window with the presentation will be shown fullscreen on that display?

Is it important that these possibilities are all shown in the same dialog? One solution that is possible without adding to the Presentation API is to use window.open() followed by document.requestFullscreen()

There's also the Window Placement API in incubation, which would allow you to place a fullscreen document on the current display or an external display. That may be a better fit depending on your use case.

[dlibby-]

Yes, your understanding is correct.

I don't think window.open() + requestFullscreen() would typically work as user activation is not preserved across window.open() calls (it's been a while since I tested this so perhaps this has changed, or is open for debate).

Window Placement looks like it would suffice in terms of being able to achieve the end result. Prior to that, I don't believe there was any way to detect this particular scenario.

I believe one goal that wouldn't be satisfied by Window Placement would be that the webpage must maintain separate codepaths. Whereas a window.open solution would probably postMessage between opener/opened window, the flow for successfully using Presentation API would use PresentationConnection.send. Similarly, monitoring disconnection/window closing would require different code.

[anssiko]

@dlibby- closed #476 a while ago so I'll close this PR as well.