Intent to ship: Presentation API on Fennec

[Shih-Chiang Chien]

Hi all,

In Bug 1318214 <https://bugzilla.mozilla.org/show_bug.cgi?id=1318214> I've
default enabled Presentation API on Fennec nightly, which allow web page to
use Google Chromecast/Nexus Player as a extended screen.

We implement 1-UA mode described in spec. Session resumption and many-to-1
session is not available in this mode.

The release plan of this API on Firefox desktop is still under discussion.

Google have release this API on both desktop and Android browser for 2-UAs
mode (see https://www.chromestatus.com/feature/6676265876586496), which
allows web page to communicate with Chromecast receiver apps. They are
implementing 1-UA mode as well, see
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HZ_ZHEE9oDo

For interoperability, W3C Second Screen CG have initiate the discussion of
defining open protocol for presentation control and video casting.

If you found any issue please file bugs and set dependency to Bug 1184036
<https://bugzilla.mozilla.org/show_bug.cgi?id=1184036>.

link to spec: https://www.w3.org/TR/presentation-api/

Platform coverage: Firefox for Android

Estimate of target release: Firefox 53

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

[Boris Zbarsky]

On 12/2/16 6:11 AM, Shih-Chiang Chien wrote:
> We implement 1-UA mode described in spec. Session resumption and many-to-1
> session is not available in this mode.

.....

> Google have release this API on both desktop and Android browser for 2-UAs
> mode (see https://www.chromestatus.com/feature/6676265876586496), which
> allows web page to communicate with Chromecast receiver apps. They are
> implementing 1-UA mode as well, see
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HZ_ZHEE9oDo

Just to make sure I understand:

1) Google ships "2-UAs" mode. On which platforms?
2) We are planning to ship 1-UA mode on Android only, for the moment.
3) Google is implementing 1-UA mode on desktop only, for the moment.

Is that a correct summary of the current interop situation?

If it is, I have some questions:

A) How are sites expected to make use of this in practice given the above?
B) If a site is written to Google's 2-UAs implementation, what happens
when it runs in Firefox with the 1-UA implementation? Can it detect
that it's dealing with a 1-UA implementation instead of a 2-UAs one?
Does it need to do such detection? Do sites do it in practice?

Do we have any indications from Apple or Microsoft as to whether they
plan to implement this API?

-Boris

[Mounir Lamouri]

On Fri, 2 Dec 2016, at 15:09, Boris Zbarsky wrote:
> On 12/2/16 6:11 AM, Shih-Chiang Chien wrote:
> > We implement 1-UA mode described in spec. Session resumption and many-to-1
> > session is not available in this mode.
> .....
> > Google have release this API on both desktop and Android browser for 2-UAs
> > mode (see https://www.chromestatus.com/feature/6676265876586496), which
> > allows web page to communicate with Chromecast receiver apps. They are
> > implementing 1-UA mode as well, see
> > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HZ_ZHEE9oDo
>
> Just to make sure I understand:
>
> 1) Google ships "2-UAs" mode. On which platforms?

Mobile and Desktop. Chrome Android supports Cast devices. On desktop I
believe DIAL is also supported.

> 2) We are planning to ship 1-UA mode on Android only, for the moment.
> 3) Google is implementing 1-UA mode on desktop only, for the moment.

Correct. Intent to ship has been sent on blink-dev. Chrome Android
should follow.

> Is that a correct summary of the current interop situation?
>
> If it is, I have some questions:
>
> A) How are sites expected to make use of this in practice given the
> above?
> B) If a site is written to Google's 2-UAs implementation, what happens
> when it runs in Firefox with the 1-UA implementation? Can it detect
> that it's dealing with a 1-UA implementation instead of a 2-UAs one?
> Does it need to do such detection? Do sites do it in practice?

The answers to these two questions is very similar. The spec allows to
pass an array of URLs to the `PresentationRequest` constructor. That
will allow developers to pass Chrome Cast, DIAL and HTTP links (usually
called 1-UA mode). Potentially also a Firefox OS TV app URL if they are
still different from regular HTTP links.

Assuming a website only cares for Chrome Cast support (ie. a variation
of 2-UA mode), the implementation will expose whether there are
available displays to use. Assuming an implementation doesn't support
Chrome Cast, the website will believe that there is no device available
around, the same way as an implementation supporting the device but
without one available.

> Do we have any indications from Apple or Microsoft as to whether they
> plan to implement this API?

Apple has been contributing to the discussions. I would say that they
showed interest but as usual, we can't deduce any implementation plans.
As far as I know, Microsoft never said anything about this API.

-- Mounir

[Boris Zbarsky]

On 12/5/16 3:20 AM, Mounir Lamouri wrote:
> Correct. Intent to ship has been sent on blink-dev. Chrome Android
> should follow.

Do you have any idea what the timeframe is?

> The answers to these two questions is very similar. The spec allows to
> pass an array of URLs to the `PresentationRequest` constructor. That
> will allow developers to pass Chrome Cast, DIAL and HTTP links (usually
> called 1-UA mode). Potentially also a Firefox OS TV app URL if they are
> still different from regular HTTP links.

OK, but a website doing this won't work in Chrome Android. So what
would websites actually do in practice?

-Boris

[Mounir Lamouri]

On Sat, 10 Dec 2016, at 17:58, Boris Zbarsky wrote:
> On 12/5/16 3:20 AM, Mounir Lamouri wrote:
> > Correct. Intent to ship has been sent on blink-dev. Chrome Android
> > should follow.
>
> Do you have any idea what the timeframe is?

Unfortunately not. My best guestimate is 2017 but that's probably too
vague :)

> > The answers to these two questions is very similar. The spec allows to
> > pass an array of URLs to the `PresentationRequest` constructor. That
> > will allow developers to pass Chrome Cast, DIAL and HTTP links (usually
> > called 1-UA mode). Potentially also a Firefox OS TV app URL if they are
> > still different from regular HTTP links.
>
> OK, but a website doing this won't work in Chrome Android. So what
> would websites actually do in practice?

Not sure what you mean wouldn't work. If a website is a good web citizen
and uses PresentationRequest with an array of URLs such as
['http://example.com', 'cast://example', 'dial://example',
'mozapp://example' ], Chrome Android will work fine because it will use
the "cast://" URL. If a website only uses the 'http://example.com' URL,
Chrome Android browsers will appear as if there are no devices
available. Either way, the website shouldn't be able to notice the
difference. Users might realise that some browsers are able to pick up
some devices and some are not.

-- Mounir

[Boris Zbarsky]

On 12/11/16 8:47 AM, Mounir Lamouri wrote:
> On Sat, 10 Dec 2016, at 17:58, Boris Zbarsky wrote:
>> OK, but a website doing this won't work in Chrome Android. So what
>> would websites actually do in practice?
>
> Not sure what you mean wouldn't work. If a website is a good web citizen
> and uses PresentationRequest with an array of URLs such as
> ['http://example.com', 'cast://example', 'dial://example',
> 'mozapp://example' ], Chrome Android will work fine because it will use
> the "cast://" URL.

I may just be missing something or misunderstanding how the API works...

Is the 1-UA vs 2-UAs mode thing transparent to the page? Based on the
descriptions of the modes it sounded to me like you can do things in at
least 2-UAs mode that you can't do in 1-UA mode; not sure about vice
versa. So presumably it's not entirely transparent? Or is the idea
that anything that works in 1-UA mode is available in 2-UAs mode and the
APIs are identical for that subset of functionality, so a page that
pretends like it's always working with 1-UA mode will just work with
2-UAs mode?

-Boris

[Mounir Lamouri]

What specifically do you have in mind when you say that 1-UA mode might
lack features? Technically, 1-UA mode is when a page is rendered on the
client and sent to the remote device. It's mostly a technical detail
because one can't render HTML pages on a Chrome Cast without creating an
application, Chrome folks call pure HTML rendering 1-UA mode. It is
fairly similar to tab mirroring. I don't think any feature should be
lacking except maybe access to the APIs on the other device.

-- Mounir

[Boris Zbarsky]

On 12/12/16 4:57 AM, Mounir Lamouri wrote:
> What specifically do you have in mind when you say that 1-UA mode might
> lack features?

The use of APIs on the other device that you mention.

-Boris