- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Wed, 17 Sep 2014 13:28:55 +0000
- To: "mark a. foltz" <mfoltz@google.com>
- CC: "public-webscreens@w3.org" <public-webscreens@w3.org>, Anton Vayvod <avayvod@google.com>, Yuri Wiitala <miu@google.com>, Derek Cheng <imcheng@google.com>
Hi MarkFo, On 16 Sep 2014, at 00:46, mark a. foltz <mfoltz@google.com> wrote: > Yes. Here is an example. The first call to |startSession()| will ask the user to select a screen before resolving p1. In the meantime the page makes another presentation request. > > var p1 = startSession(myUrl); > var p2 = startSession(myUrl2); > > Here is what I had in mind: > > (1) First call to startSession(myUrl) shows the dialog and returns a Promise. > (2) At this point any further calls to startSession() from within the same top level document (i.e., tab) return a Promise that never resolves. > (3a) If the user accepts the presentation request, the Promise in #1 resolves with the PresentationSession. > (3b) If the user rejects the presentation request, the Promise in #1 never resolves. > (4) After (3a) or (3b) happens, calls to startSession() will return a Promise that resolves in the normal way (same as #1). > > If we allow concurrent calls to startSession() from the same document, then we would have to queue them up and it would be a confusing user experience to show multiple dialogs (how would they know which content is requesting what). > > Practically speaking, this is unlikely to happen (at least in Chromium): the screen selection dialog is modal, blocking user input to the underlying page, and if possible, we will likely require a user gesture to cause the invocation of startSession(). This is aligned with my thinking on how I envision this might work. Thanks for the example. Thanks, -Anssi
Received on Wednesday, 17 September 2014 13:31:33 UTC