Re: Updated Presentation API WebIDL - call for review

IL

On Thu, Apr 17, 2014 at 2:39 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> Hi MarkFo, All,
>
> On 15 Apr 2014, at 01:38, mark a. foltz <mfoltz@google.com> wrote:
>
> > Thanks for the detailed response and sorry for the late reply -
> >
> > So it seems the approach that is satisfactory is to leave the placement
> of the screen selection dialog up to the user agent.  If the UA wishes to
> place the dialog within the viewport (as mobile Safari does with <input
> type="file">) it can, but that's not going to be required by any part of
> the Presentation API.
>
> Agreed. To reach an agreement on this issue — does anyone object [with
> good reasons :)] to us leaving the screen selection dialog positioning up
> to the UA?
>
> [...]
>

Sound good to me.


>
> > I'm certainly not opposed to browsers using context menus if they feel
> that's the best UX to expose this feature, as long as we're not making it
> an implementation requirement.  I think it might make sense in certain
> contexts, such as the context menu for a <video> element, but not as a
> general mechanism to open up to the Web.
>
> I think we should not make it an implementation requirement, it just
> provides web developers a means to invoke requestSession() in the context
> of the element. Alternative would be to use a <button> positioned
> underneath the <video> element, for example.
>

Either of those make sense to me as affordances Web developers might want
to provide for their <video> element.  However I'm still unclear on how the
developer links the <video> element to the context menu (see below).


>
> > For example, how would the site be able to create markup to populate the
> menu without being able to enumerate all available screens?
>
> The site would not be able to get the enumeration, rather the *UA* could
> present the enumeration in the context of the click that invoked
> requestSession() if it wishes to, similarly to the iPad <input type=file>
> discussed earlier. This would be an implementation detail, and some
> implementations might prefer alternative mechanisms, such as displaying the
> enumeration in the chrome in an infobar as per the currently prevalent
> practice.
>

I think I see what you are saying - let me try to be a bit more concrete.
 It seems like there are two modes of operation we could support:

(1) Web developer adds his own UX to enable presentation, via a <button> or
other UI, and handles establishing the presentation via the
NavigatorPresentation API (i.e., sending the video URL over to the remote
screen).  If the Web developer wants to use a context menu on a <video>
element for this, he can have the menu item trigger the
NavigatorPresentation.requestSession() method, which triggers the UA's
enumeration interface.

(2) Web developer marks up <video> to allow the UA to enable presentation
via an attribute, i..e enable-presentation="true".  UA generates a
"default" interaction model for remote presentation of <video>, using a
context menu, browser chrome, or customizing the local rendering of <video>
controls.  (In some cases the UA may determine that the video is able to be
presented remotely without any special attributes and acts as if the
attribute were set.)  In this case the screen enumeration *might* appear
directly in the context menu since the menu item is under the UA's control
and not available to the page.


> Btw. we’re discussing an analogous enumeration issue in another group in
> the context of getUserMedia() and getMediaDevices() and people have
> concerns:
>
>   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25245
>
> Allowing web content to access the enumeration of [hardware] devices is a
> generic issue that is shared with other privacy-sensitive APIs on the
> platform. I suggest we do not try to solve this issue in isolation. When
> the getMediaDevices() issue is resolved we could reuse that, and meanwhile
> more forward in other areas of the API.
>

Yes, we should see what conclusions they draw and go from there.  It wasn't
clear from the linked discussion the use case for an enumeration API at all
though.


>
> Does that sound reasonable?
>
> To summarize, I’d like the group to agree on the following:
>
> 1) The screen selection dialog positioning is up to the implementation.
>

SGTM


> 2) Web content cannot get access to the enumeration of the screens, rather
> the UA mediates the selection and passes a PresentationSession to the web
> content as per the user’s selection.
>

SGTM


>
> Please let us know if you have concerns with the above so we can close
> these issues.
>
> Thanks,
>
> -Anssi