Re: Presentation API changes proposal

Hi Anton, All,

On 09 Jan 2014, at 23:35, Anton Vayvod <avayvod@google.com> wrote:

> Replying to this email separately since it didn't get into the Dominik's reply:
> 
> 
> On Wed, Jan 8, 2014 at 10:46 AM, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote:

[...]

> > With that in mind, the first change we would like to propose to the API is as follows:
> >
> > Promise requestShow(optional DOMString url = "about:blank", optional boolean infinitePlay = false); [3]
> >
> > Calling requestShow with a url of a session in progress would return the WindowProxy (or MessagePort) of the session in progress instead of prompting the user.
> 
> I guess there would be no prompt only if there already exists a session identified by an url and infinitePlay is set to true? Am I right that the infinitePlay flag controls whether the media will continue to play even if the browsing context from which the requestShow() was called is destroyed?
> 
> Yes. We may step further and decide that the controller is always responsible for closing the presentation window onunload if it can always reconnect to the existing session. Then the flag would not be necessary though some extra work would be needed from developers using the API for the same UA rendering (to close the second screen window and to reconnect to it if the controller crashes/navigates/reloads).

If there are good use cases for explicitly declaring a session to be either persistent or non-persistent, and we set the default so it makes the most common case simple (defaults to false in this case), then keeping a flag sounds right.

> The step 4 of the /algorithm to request access to the presentation display/ currently says:
> 
> [[
> 
> * Prompt the user's permission or check that the setting for allowing access to a presentation display enabled. If no permission is given, jump to the step labeled failure below. If the user never responds, this algorithm will never progress beyond this step.
> 
> ]]
> 
> We may need define a "check that the setting for allowing access to a presentation display” process (should make the name more concise), and clarify this detail in it. Also some other steps may need to be adjusted a bit. Do you already have a concrete proposal in mind how you’d like to change the algorithm?
> 
> No, we haven't thought about the exact wording change yet. I think the user will have to allow the controller origin to launch/connect to a particular URL on each presentation display and the UA will remember if the user granted the permission (so we can allow foo.com to launch/connect to foo.com/play on display A but not anything on display B or boo.com/present on device A). Or maybe it doesn't make sense to grant permissions per displays?

I think we may want to make this an implementation detail in the spec to allow UAs to innovate in terms of the user experience. Some implementations may prefer to grant permission per display as you suggest, while others may want to always ask the user. To allow this, we should define what granting a permission means, for example:

[[

A secondary display can only be used to display content if the user (or the User Agent on behalf of the user) has granted permission. The *permission* to display content on a particular secondary screen for a given URL can be true or false, indicating whether the permission has been granted. 

]]

Then, in the algorithm itself, check for this flag and act accordingly.

[...]

> Btw. How in the flinging use case you’d identify a session? Is the url enough (e.g. use a query string and/or fragment identifier to conveying the session information), or is something else required? For example, how about a use case where a video from the same url is being played on two separate secondary displays?
> 
> The URL of the receiver page should be enough. All additional information about the existing session is passed back to the controller when it connects over the MessagePort. In the example you provide, this would be two separate sessions, at least for flinging. Could you elaborate on the example? Do you mean that the UA might want to render the second screen content once and then present it on both displays?

Ok, let me elaborate what I had in mind. The user has the same content, say a web-based video player served from the same URL open in multiple tabs. One of the tabs is showing the video on the secondary display, while the other tab tries to do the same. What would be the intended behaviour?

I’d guess it might make sense to allow the UA to inform the user before taking over the secondary display that the display is busy and allow the user to have a say? Both the pages to be shown on the secondary display are identified by the same URL, and have their persistent flag set.

Is this an issue? Perhaps we just need to clarify in the spec what an “available display” means. Or should we leave this up the the implementation?

> > On top of this change, we’d also like to explore two other things that would make the API easier to implement and use.
> >
> > Promise searchSecondScreens(optional DOMString url);
> >
> > This would replace displayAvailable and onDisplayAvailableChange. The promise would return true if there is at least one display available for this url. The implementation of the method can certainly cache devices and keep a similar displayAvailable + event handler mechanism internally.
> 
> In addition to making the API more future-proof, this would actually be a requirement for the flinging use case to work if I’m not mistaken? There must be a means to filter the search with an url that identifies a session (if enough to identify a session, that is).
> 
> Correct. The URL also allows to filter second screens out: Chromecast only supports a whitelist of URLs, smart TVs might only allow launching YouTube or Netflix but not foo.com while rendering locally would allow any URL.

Whitelisting based on an URL sounds like a reasonable mechanism for filtering, considering the implementation constraints for the flinging use case. 

I’m wondering whether the user may get confused, if a particular secondary display may only be used to display content from a subset of services. This could be mitigated by cleverly designer a “screen picker”, i.e. by graying out devices that that are not supported.

> Other than that, this seems to be functionally-equivalent with the current design.
> 
> Except for the polling situation described by Mark and Dominik. I think the event handler is the right way to do it.

+1

> > Finally we’d like to change the spec so that the Promise object can return a small wrapper over MessagePort instead of a WindowsProxy. Implementing a full WindowsProxy will add additional and unnecessary complexity, making browser implementations harder without a need.
> 
> Do you have more details to share on how you’d propose the MessagePort to be extended?
> 
> I think Dominik presented a good example in his reply. We'd have an additional onclose event.

So instead of requestShow() returning a WindowProxy, a wrapper would be returned to the opener browsing context, right? Something like the following:

interface PresentationWindow {
  readonly attribute MessagePort port;
  attribute EventHandler onclose;
};

This would allow the opener to send messages to the auxiliary browsing context, and know when the auxiliary browsing context is destroyed (onclose).

Then, another MessagePort must be associated with the auxiliary browsing context to allow it to send messages to the opener browsing context. This could be made either implicitly as in dedicated workers, or explicitly, for example, through connect event that receives the another MessagePort.

Does this resonate with your thinking?

Thanks,

-Anssi

Received on Tuesday, 14 January 2014 17:15:09 UTC