[blink-dev] Intent to Implement and Ship: PresentationConnection.url attribute

[Bin Zhao]

Contact emails

zha...@google.com, mfo...@google.com

Spec

https://www.w3.org/TR/presentation-api/#interface-presentationconnection

TAG review of Presentation API: https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md

Summary

We would like to add a url attribute on PresentationConnection object.

Motivation

The url attribute allows the Web developer to know which URL was actually presented when a presentation is started.   The attribute was added as part of the change to allow alternative/fallback presentation URLs to be used with a PresentationRequest [1].

[1] https://github.com/w3c/presentation-api/issues/311

Interoperability and Compatibility Risk

Interoperability Risk: Mozilla (who is also implementing the Presentation API) requested the spec change.  They have already implemented it in trunk.

Compatibility Risk: Low. As is a new attribute, no Web content currently uses it.

Ongoing technical constraints

The multiple-URL PresentationRequest constructor is still in implementation, so currently url will be set to the same URL passed in the constructor.  We will send a separate intent to implement/ship for the multiple-URL constructor.

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

All except WebView (where Presentation API is not supported).

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=654110  (It was not filed following the template.  We can refile it if requested.)

Link to entry on the feature dashboard

None. It is a small change.

Requesting approval to ship?

Yes

[Philip Jägenstedt]

When do you expect to implement/ship the sequence<DOMString> variant of the PresentationRequest constructor? It seems to me that this will not be possible to feature detect, and that new PresentationRequest([url1, url2]) would stringify the argument and not throw at the bindings level. The spec prose does say "If the resolve a URL algorithm failed, then throw a SyntaxError exception", but [url1, url2].toString() will tend to be a valid URL and doesn't throw.

If this is right, then 'url' in PresentationConnection.prototype might be the best way to feature detect:

function request(urls) {

  if (!Array.isArray(urls))

    urls = [urls];

  if ('url' in PresentationConnection.prototype) {

    return new PresentationRequest(urls);

  } else {

    return new PresentationRequest(urls[0]);

  }

}

Does that make sense? If so, would it be better to ship these changes together?

(Looking at https://w3c.github.io/presentation-api/#interface-presentationrequest, TR/ is several months out of date.)

[mark a. foltz]

On Fri, Oct 21, 2016 at 1:51 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

When do you expect to implement/ship the sequence<DOMString> variant of the PresentationRequest constructor? It seems to me that this will not be possible to feature detect, and that new PresentationRequest([url1, url2]) would stringify the argument and not throw at the bindings level. The spec prose does say "If the resolve a URL algorithm failed, then throw a SyntaxError exception", but [url1, url2].toString() will tend to be a valid URL and doesn't throw.

To my surprise, you're absolutely correct.  Thanks for the insights.

 

If this is right, then 'url' in PresentationConnection.prototype might be the best way to feature detect:

function request(urls) {

  if (!Array.isArray(urls))

    urls = [urls];

  if ('url' in PresentationConnection.prototype) {

    return new PresentationRequest(urls);

  } else {

    return new PresentationRequest(urls[0]);

  }

} 

Does that make sense? If so, would it be better to ship these changes together?

I agree.  We can send an intent to implement for both now.  The DOMString[] constructor won't be ready to ship for a little while longer.

 

(Looking at https://w3c.github.io/presentation-api/#interface-presentationrequest, TR/ is several months out of date.)

I has been a while :) There have been a few minor API fixes in the interim.  We'll likely republish soon.

m.

[Philip Jägenstedt]

OK, so I've put "will ship together with new PresentationRequest constructor" in https://bit.ly/blinkintents

If that's not what you had in mind, please shout :)

[Chris Harrelson]

LGTM1 % changes Philip suggested.

--
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.