Re: How to filter available screens according to the content being presented (issue #9)

Hi Mark,

I have been thinking about this problem since our last conversation.  I
understand the use case, but have some concerns about the specific approach
proposed, which I hope can be addressed by a carefully designed API.  My
concerns:

(1) Screens may become available or unavailable over the lifetime of the
page.  To show or hide the presentation icon, the site would have to invoke
canRequestSession in a loop, if I understand correctly.  It seems like a
more natural API to use an event handler for this purpose.  The event
handler will still have the issue about whether (and when) to fire the
initial event, but avoids the use of polling loops to keep the web app user
interface in sync.

(2) I worry that a site may use this API to gather information about users,
even fingerprint them, especially if there is known content that can only
be rendered by specific type(s) of devices.  This could be mitigated by the
following changes:

(2a) Require user consent.  I don't like this.  This puts an obstacle in
front of the user that will potentially be confusing and irritating; when
actually presenting, the user will be prompted again by the browser to
select a screen.  The user may decline, which puts the site in a difficult
position of not knowing true availability.  Or the user may accept and make
it sticky, which then gives the site permission to query it at-will,
defeating the purpose of consent.

(2b) Only allow queries for a restricted set of URLs, limited by
same-origin or some other policy.  I prefer this approach but makes the API
less powerful.

(3) On mobile devices, the UA may want additional control over when
discovery happens.  Adding a query API means the UA will need to either
discover continuously, or delay answering a query until the discovery
process starts and stabilizes.  It seems to add a layer of complexity to
implementation.

(4) More of a question: Is there a use case for querying for more than one
URL per page?

===========

My proposal:

- Propose an HTML5 meta-tag [1] that names a default presentation URL for
the document, say "presentation.defaultPresentationUrl"

- If set, the UA will use that to determine when to fire
|onavailablechange| on NavigatorPresentation.  |onavailablechange| would
only be fired if a screen was able to present
|presentation.defaultPresentationUrl|.   If unset, default behavior for
|onavailablechange| applies.

- |presentation.defaultPresentationUrl| must be same-origin with the
document.  This limits the ability for pages to script this API to gather
device capabilities or fingerprint users.

This is a small change to the existing API and I believe it addresses the
concerns I outline above.  Would this meet the requirements you have in
mind?

[1] http://wiki.whatwg.org/wiki/MetaExtensions

m.





On Wed, Sep 10, 2014 at 11:03 AM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> This issue is all about ensuring that the user is not presented with a
> "present" icon which, when clicked, does nothing because there are in fact
> no available screens supporting the content.
>
> The issue suggests one approach, whereby the UA can be instructed to
> filter the available screens to those supporting specific provided URLs.
>
> Another approach would be to provide a new method:
>
> Promise<bool> canRequestSession( DOMString url );
>
> This would take exactly the same parameters as requestSession, but rather
> than prompting the user it would return a prediction of whether there would
> be any screens to prompt the user with. The application could avoid showing
> the "present" icon if there are in fact no suitable screens.
>
> ...Mark
>