Intent to Ship: Presentation API

[Stephen Konig]

Contact emails

Spec editor:

mfo...@chromium.org

Blink implementor:

mlam...@chromium.org, ava...@chromium.org

Spec

Editor’s Draft: http://w3c.github.io/presentation-api/

Working Draft: http://www.w3.org/TR/presentation-api/

Note that the working drafts are published automatically off of the ED:

https://lists.w3.org/Archives/Public/public-secondscreen/2015Jun/0065.html

Tag review info:

https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md (moved to Aug 26)

Summary

Adds support for presentation of Web content on connected displays.   Web pages may request presentation of a URL and Chrome will present it on a connected display using various screen sharing technologies implemented by Chrome.  The controlling page is able to control the presented page via two-way messaging.

Link to “Intent to Implement” blink-dev discussion

Intent to Implement conversation:

https://groups.google.com/a/chromium.org/d/topic/blink-dev/J0ToSdOQVP8/discussion

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, except for Android WebView, where underlying Android framework API changes would be required, e.g. in order to provide a device picker UI.

Demo link

https://storage.googleapis.com/presentation-api/index.html

To use this demo you'll need to launch Chromium (ToT or Canary) with the following flags (or set them in ://flags): --enable-media-router --enable-extension-action-redesign --enable-experimental-web-platform-features

You will also need a device on your local network that you can connect to; currently Cast (i.e. Chromecast) and DIAL devices are supported.

Debuggability

Promise rejections with informative messages are implemented in Blink. The external behavior of the API can be inspected using the normal Chrome developer tools, setting Javascript breakpoints, etc.

If the developer wishes to view the lower level interactions between the browser and the display, they can run Chrome with --show-component-extension-options and view console messages from the Media Router component extension.

Compatibility Risk

Low-moderate.  Mozilla has been active in the working group.  Interoperability between browsers and displays is challenging because of the proprietary nature of existing screen sharing technologies.

Mozilla tracking bug for WebIDL implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1069230.

The current implementation supports all required aspects of the specification.  However one of the features the spec describes is "1UA mode," in which content for the remote display is rendered locally by the browser (for Chromium, we plan to do this in an offscreen tab), then mirrored to the second screen using some protocol.  This is contrast to "2UA mode," in which the second screen content is fetched and rendered by the remote display itself.  1UA mode isn't presently implemented, though we do plan to add it over the remainder of this quarter (likely in time for M47).  Nonetheless, 1UA mode isn't a requirement of the spec; browser vendors can choose to support it, or not.

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=412331

Entry on the feature dashboard

https://www.chromestatus.com/feature/6676265876586496

[Torne (Richard Coles)]

Is there a bug filed for this not working on WebView?

[Stephen Konig]

I filed https://code.google.com/p/chromium/issues/detail?id=521319.

[Mounir Lamouri]

FWIW, Mozilla has another bug to match the latest iteration of the
specification (the one we want to ship). According to the flags set on
the bug, they intend to ship this with Firefox OS 2.5.
https://bugzilla.mozilla.org/show_bug.cgi?id=1192101

Regarding WebView, after talking to Torne, there are many issues that
prevent us from shipping. We are going to entirely disable the API on
WebView.

-- Mounir

> >> Entry on the feature dashboard <http://www.chromestatus.com/>
> >>
> >> https://www.chromestatus.com/feature/6676265876586496
> >>
> >>
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Rick Byers]

I see there are a number of issues in the spec (inline and in GitHub).  Some sound to me like they might be breaking changes.  Personally I think it's fine to ship an API with some open issues as long as we believe we could resolve those in a highly compatible fashion.  But if there's open debate about changing behavior in an incompatible way, then we should probably block on that debate until we ship the specific API affected by it.  Thoughts?

Has any attempt been made to reach out to Microsoft or Apple to get their feedback on this API?

[Domenic Denicola]

From: rby...@google.com [mailto:rby...@google.com] On Behalf Of Rick Byers

> Has any attempt been made to reach out to Microsoft or Apple to get their feedback on this API?

+Travis Leithead has provided some feedback as a TAG review, but I don't want to presume that he's speaking for Microsoft given that it was in his capacity as TAG member: https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md

[Mounir Lamouri]

On Mon, 17 Aug 2015, at 18:13, Rick Byers wrote:
> I see there are a number of issues in the spec (inline and in GitHub).
> Some sound to me like they might be breaking changes. Personally I think
> it's fine to ship an API with some open issues as long as we believe we
> could resolve those in a highly compatible fashion. But if there's open
> debate about changing behavior in an incompatible way, then we should
> probably block on that debate until we ship the specific API affected by
> it. Thoughts?

Anton and I triagged the issues today. We found a few that we would
consider important with regards to the I2S:
https://github.com/w3c/presentation-api/issues/35 - the change would
likely be forward compatible and worst case, shouldn't be hard to
implement (adding a new state).
https://github.com/w3c/presentation-api/issues/149 - the change is
definitely forward compatible.
https://github.com/w3c/presentation-api/issues/152 - this is a minor
change, not forward compatible but just renaming an event (if we do).
https://github.com/w3c/presentation-api/issues/91 - we do not implement
the receiving API yet so if we ship the client side, I assume the client
API will stay in the current namespace and the receiving API might move.
https://github.com/w3c/presentation-api/issues/99 - we do not implement
the receiving API yet.
https://github.com/w3c/presentation-api/issues/153 - it's a general and
vague issue, no real action item at the moment.

> Has any attempt been made to reach out to Microsoft or Apple to get their
> feedback on this API?

Apple never gave opinions about the work AFAIK. However, they were
members of the CG [1]. I know there were attempts from the team to reach
out to them but it never succeeded.
The team had discussions with Microsoft but they did not seem
interested. AFAIK, it is mostly because they do not consider the UC as a
priority.

[1] https://www.w3.org/community/webscreens/participants

-- Mounir

[Anne van Kesteren]

On Tue, Aug 18, 2015 at 12:38 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> https://github.com/w3c/presentation-api/issues/153 - it's a general and
> vague issue, no real action item at the moment.

That seems like the biggest issue of them all. It confirms that this
is basically an API atop of a protocol which is not standardized.


--
https://annevankesteren.nl/

[Anton Vayvod]

On Tue, Aug 18, 2015 at 11:42 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Aug 18, 2015 at 12:38 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> https://github.com/w3c/presentation-api/issues/153 - it's a general and
> vague issue, no real action item at the moment.

That seems like the biggest issue of them all.

I agree with you. The issue is essentially the first tiny step towards a standartization project for a network communication protocol for device discovery and messaging (i.e. within IETF), but I don't expect it to affect the spec since the API is protocol agnostic by design. Not does it feel to be in the scope of the Second Screen WG. So the issue is not significant in terms of the spec being stable enough to ship.

 

It confirms that this
is basically an API atop of a protocol which is not standardized.

Shipping the API on top of an existing protocol would not only allow iterating on the spec if it doesn't address some use cases well, but also to understand the requirements for a future open protocol better.

 

--
https://annevankesteren.nl/

[Anne van Kesteren]

On Tue, Aug 18, 2015 at 2:59 PM, Anton Vayvod <ava...@chromium.org> wrote:
> I agree with you. The issue is essentially the first tiny step towards a
> standartization project for a network communication protocol for device
> discovery and messaging (i.e. within IETF), but I don't expect it to affect
> the spec since the API is protocol agnostic by design.

That sounds fairly naive, if not simply wrong. As you mentioned later
in your email API and protocol need to iterate together. You cannot do
either in isolation and somehow end up addressing all the
requirements.


--
https://annevankesteren.nl/

[Anton Vayvod]

I meant that some protocol properties might be derived from the real world usage of the existing protocols via the API. The current spec already proved to fit a few existing protocols: Cast, DIAL, the one that Mozilla is implementing, so I don't believe the spec will have to be changed significantly because of yet another protocol.

--
https://annevankesteren.nl/

[Kenneth Rohde Christiansen]

Plus, at Intel we have implemented it in Crosswalk based on Miracast.

Kenneth

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

LGTM!

I think there is non-trivial risk here that because this has been implemented on top of Chromecast in Chromium and much of the spec work has been done by Googlers, that certain certain design decisions in the Presentation API will turn out to be problematic for some other protocols. However, such a generic concern isn't really actionable, so unless there's concrete feedback of this kind, there isn't much to do except to accept the risk.

By happenstance I honed in on such a case, namely getAvailability() and what it implies for how the discovery works, i.e. does discovery need to be running indefinitely in the background? However, in that case I think the solution looks sound and https://github.com/w3c/presentation-api/issues/161 is going to fix a spec bug in this area.

I think this will be a valuable addition to the web platform.

[Rick Byers]

I agree with your articulation here Philip.  I'm happy to hear that Intel have implemented this for Miracast, hopefully that decreases the risk Anne is concerned about a little.  If we uncover additional interoperability issues in the future when there are more shipping implementations, I'm confident that we'll continue to work to address those.  The cost of adding some new fixed API (and potentially deprecating some old API), while non-trivial (adding unnecessary baggage to the platform) is not as bad IMHO as the cost of speculatively delaying shipping an important feature like this.

In general, if the implementing engineers and spec editors agree that the APIs we want to ship now are probably stable in the spec, then I'm also OK with shipping.

It sounds like perhaps this is the only known potential breaking change:

> https://github.com/w3c/presentation-api/issues/152 - this is a minor

> change, not forward compatible but just renaming an event (if we do).

Can we get consensus on that issue before shipping?  Shipping before there is consensus is potentially the same thing as resolving the issue by fiat (saying we might be prevented from ever changing it because we're locked into it).

Since Mozilla is also actively implementing it would be really helpful to get confirmation from the engineer working on their implementation that they aren't aware of any other specific issues that would require the API to change.  Anne / Anton, can you reach out to whoever that is to see if they have any concrete spec issues they'd prefer we wait for consensus around?

Rick

[Mounir Lamouri]

The issue was filed by Mark Foltz (Google). Resolving that issue
(whether WontFix or updating Blink) should be very simple and we can
discuss that with Mark tomorrow when he is back in the office. I
wouldn't worry about that. On the Blink side, the change if it were to
happen would be a string update. (IMO, the current event name is fine,
FWIW.)

> Since Mozilla is also actively implementing it would be really helpful to
> get confirmation from the engineer working on their implementation that
> they aren't aware of any other specific issues that would require the API
> to change. Anne / Anton, can you reach out to whoever that is to see if
> they have any concrete spec issues they'd prefer we wait for consensus
> around?

Anton and I had a lengthy meeting with Mozilla to discuss the most
recent API changes. The outcome of the meeting was that they were happy
with the changes and the specification generally speaking. We clearly
asked them if they were okay with us shipping the API in its current
shape and they had no objection. They sent a few comments afterwards but
AFAICT no serious issues. Mark Foltz has been handling these so I do not
know the details.

-- Mounir

[Noel Gordon]

Mounir,

Question: say i'm on retina and chrome is creating rendered frames for presentation, but I'm presenting on a non-retina device. How's does that work?

~noel

[Anton Vayvod]

The sender device display characteristics don't affect the presentation page, as the presentation page is never shown on the sender device display. In 1-UA mode the page is rendered offscreen, so the UA will supply the right values to window.screen and similar properties as needed. These will try to match the properties of the presentation display if possible or the stream I suppose.

[Mounir Lamouri]

It's a good question Noel. We will have to provide a different
window.screen for the off-screen page (1-UA mode) to make sure
responsive websites render something close to what they should
theoretically render. However, this Intent to Ship isn't including
off-screen rendering so it's something we will have to take care of for
the next steps of the API.

As Anton said, for the feature we are shipping, it doesn't change
anything because the target device will render locally.

-- Mounir

[Noel Gordon]

Right.  Perhaps file a spec issue about it if the API intends to deal with differing target display device characteristics (dpi, color space, etc).

[Dimitri Glazkov]

LGTM2.

[Rick Byers]

Can you guys please clarify exactly which APIs in the spec are being shipped at this time?  Would it also make sense to fork the chromestatus.com entry so developers can more easily understand what we're shipping now, and what APIs are still coming in a future version?

What's your take on the TAG feedback?  Some of it sounds like maybe it could lead to wanting to make a breaking change to the API.  In particular, Domenic's idea of using the writable stream API here (rather than introduce but-yet-another special-purpose stream API) sounds to me like it might have some merit but may not be worth waiting for.  It's up to the WG to weigh the tradeoffs and decide - but IMHO we should know the conclusion of that discussion before shipping.

Rick

[Domenic Denicola]

From: rby...@google.com [mailto:rby...@google.com] On Behalf Of Rick Byers

> What's your take on the TAG feedback?  Some of it sounds like maybe it could lead to wanting to make a breaking change to the API.

I am curious on the answer to this to. The feedback about how it is similar-to but subtly-different-from other existing APIs, like postMessage and Fullscreen, seemed especially interesting. I didn't see those points addressed in the TAG issues label https://github.com/w3c/presentation-api/labels/TAG.

> In particular, Domenic's idea of using the writable stream API here (rather than introduce but-yet-another special-purpose stream API) sounds to me like it might have some merit but may not be worth waiting for.  It's up to the WG to weigh the tradeoffs and decide - but IMHO we should know the conclusion of that discussion before shipping.

Thanks for highlighting this! I opened a bigger issue explaining how both readable and writable streams would work well here: https://github.com/w3c/presentation-api/issues/163

But I really don't want to put writable streams on the critical path for this API. Or for any others, at least until I am confident they are ready. So please don't wait :). Streams are in that kind of awkward phase that you may remember from the early days of promises, where they are gelling into something we can start spreading everywhere, but aren't quite there yet.

That said, if any of the spec editors or Blink implementers have encouraging comments along the lines of "yes, that sounds like a good idea, we're very interested in doing so as soon as you send us a spec pull request" I'd be happy to hear that :). Or negative comments too, of course! The silence is a bit unnerving.

[Anton Vayvod]

On Tue, Aug 25, 2015 at 8:02 PM, Domenic Denicola <d...@domenic.me> wrote:

From: rby...@google.com [mailto:rby...@google.com] On Behalf Of Rick Byers

> What's your take on the TAG feedback?  Some of it sounds like maybe it could lead to wanting to make a breaking change to the API.

I am curious on the answer to this to. The feedback about how it is similar-to but subtly-different-from other existing APIs, like postMessage and Fullscreen, seemed especially interesting. I didn't see those points addressed in the TAG issues label https://github.com/w3c/presentation-api/labels/TAG.

We did discuss fullscreen numerous times on the mailing list and on GitHub (Mark summarizes the differences and why the group feels our open-window-like approach fits the use cases better).

In the initial version of the API postMessage(DOMString) was the way to send messages to the presentation page and back. Mozilla suggested to switch to WebRTC DataChannel interface (send()) that was better suited for cross-origin cross-device communication. We're not introducing anything new here but picking one of the two existing interfaces.

> In particular, Domenic's idea of using the writable stream API here (rather than introduce but-yet-another special-purpose stream API) sounds to me like it might have some merit but may not be worth waiting for.  It's up to the WG to weigh the tradeoffs and decide - but IMHO we should know the conclusion of that discussion before shipping.

Thanks for highlighting this! I opened a bigger issue explaining how both readable and writable streams would work well here: https://github.com/w3c/presentation-api/issues/163

Yeah, I think we're looking forward for adding Streams-based messaging API (e.g. if other browser vendors support that too) to the spec but I'm afraid will have to ship initially with what already exists and has group's consensus.

But I really don't want to put writable streams on the critical path for this API. Or for any others, at least until I am confident they are ready. So please don't wait :). Streams are in that kind of awkward phase that you may remember from the early days of promises, where they are gelling into something we can start spreading everywhere, but aren't quite there yet.

That said, if any of the spec editors or Blink implementers have encouraging comments along the lines of "yes, that sounds like a good idea, we're very interested in doing so as soon as you send us a spec pull request" I'd be happy to hear that :). Or negative comments too, of course! The silence is a bit unnerving.

Sorry about the silence. Our main focus is on the few issues blocking this thread right now and your issue was categorized into the bucket of future additions to the spec.

[Chris Harrelson]

LGTM3

[hubert.sa...@gmail.com]

Hey, I tried the demo!!

It pops me the device selection UI ok but it "only" launches default media receiver without any media playing.

I also tried to use an APP_ID I registered with the same URL, it does not display it on the Chromecast...

Any clues? Is there any other demo somewhere?

[Mounir Lamouri]

Thank you fit your interest Hubert! I believe there is a demo link in
the original post from Stephen. Feel free to send me and Anton feedback
directly.

-- Mounir

On Wed, 26 Aug 2015, at 17:48, hubert.sa...@gmail.com wrote:
> Hey, I tried the demo!!
>
> It pops me the device selection UI ok but it "only" launches default
> media
> receiver without any media playing.
> I also tried to use an APP_ID I registered with the same URL, it does not
> display it on the Chromecast...
>
> Any clues? Is there any other demo somewhere?
>
> Le samedi 15 août 2015 18:00:40 UTC+2, Stephen Konig a écrit :
> >
> > Contact emails
> >
> > Spec editor:
> >

> > mfo...@chromium.org <javascript:>
> >
> > Blink implementor:
> >
> > mlam...@chromium.org <javascript:>, ava...@chromium.org <javascript:>

> > Entry on the feature dashboard <http://www.chromestatus.com/>
> >
> > https://www.chromestatus.com/feature/6676265876586496