Intent to Implement and Ship: sequence<DOMString> constructor for PresentationRequest and url attribute for PresentationConnection
mark a. foltz
Intent to Implement and Ship: sequence<DOMString> constructor for PresentationRequest and url attribute for PresentationConnection
Contact emails
mfo...@google.com, zha...@google.com
Spec
This is a non breaking incremental change to a shipping API (Presentation API).
Spec: https://w3c.github.io/presentation-api/#interface-presentationrequest and https://w3c.github.io/presentation-api/#interface-presentationconnection
PR: https://github.com/w3c/presentation-api/pull/316
TAG review of Presentation API: https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md
Summary
This change adds a new sequence<DOMString> constructor to PresentationRequest taking multiple URLs, in addition to the existing constructor that takes a single URL. When checking for availability of displays, all URLs will be considered. When starting a presentation, the browser will choose the first URL in the sequence that can be shown on the selected presentation display. On success, the URL presented is returned as PresentationConnection.url.
Motivation
Currently, authors have to use a single URL to designate the content to be displayed on the presentation screen. There is a fragmentation of supported protocols (Cast, DIAL, Firefox OS proprietary protocol) that are not all supported by a given user agent. While the Open Second Screen protocol is being worked on and to avoid user agent sniffing, a list of URLs can be use to accommodate the different user agents and their protocol support.
Interoperability and Compatibility Risk
The change is backwards compatible, as the single URL constructor will be retained. Authors can feature detect the existence of the multiple URL constructor by checking for PresentationConnection.url since we are shipping both at the same time.
The change improves interoperability: additional schemes for designating presentation content can be passed as separate URLs, and a browser that doesn’t support a given scheme can ignore it. For example, Chrome can handle Cast applications by accepting URLs in the form cast://<parameters>, and Firefox can support Firefox TV applications by accepting URLs in the form app://<parameters>.
Mozilla and Apple are supportive of the change as discussed in the Second Screen WG F2F in May 2016:
https://www.w3.org/2016/05/25-webscreens-minutes.html#item03
Mozilla has already implemented it on trunk:
https://hg.mozilla.org/mozilla-central/file/tip/dom/webidl/PresentationRequest.webidl
Ongoing technical constraints
None anticipated.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All. (WebView has disabled the Presentation API, but this change itself does not add incompatibility with WebView.)
OWP launch tracking bug
None, implementation bug: http://crbug.com/627655.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5687338902487040
Requesting approval to ship?
Yes. We plan to ship in M56 but may slip to M57.
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Philip Jägenstedt
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
