Re: Updated Presentation API WebIDL - call for review

On Mon, Apr 21, 2014 at 7:55 PM, mark a. foltz <mfoltz@google.com> wrote:

> 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.
>

​I would support both of these options. I still don't think the proposed
API supports all the use-cases with these options, though:

For (1), the site needs to know whether or not to show the UI element for
second screen. We would like only to do this if there is a second screen
available that supports presentation or flinging of the content we will
render. For the Mirracast & remote UA cases, this is easy as such displays
can render any content, but for the flinging case, the remote display may
be, for example, a Netflix App on a TV which can render only
netflix.comURLs. So,there needs to be a way for the site to specify
the URL in order
for it to get back the information as to whether a suitable display exists,
so it can decide whether to show the UI element.

For (2), similarly, the UA needs to know the URL so that it can decide
whether to show this UI element itself. A URL may be provided through the
src attribute or <source> element, but also the site may use the Media
Source Extension.

...Mark




>
>
>> 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
>
>
>