Fix bugs related to PresentationSession.url attribute

[obeletski]

Specification refers to the url attribute [2] of the PresentationSession that is not a part of PresentationSession interface [1]. We can do two different things - either add that to the interface [3] or remove from the steps description [4].

I share @schien's point of view about the difficulties of obtaining correct url on the presenting page especially taking into account DIAL, HbbTV and other technologies.

[1] http://w3c.github.io/presentation-api/#interface-presentationsession [2] http://w3c.github.io/presentation-api/#starting-a-presentation-session [3] https://lists.w3.org/Archives/Public/public-secondscreen/2015Jun/0034.html [4] https://lists.w3.org/Archives/Public/public-secondscreen/2015Jun/0036.html

[markafoltz]

The idea was that it would reflect the URL used to start the presentation - it would not necessarily reflect the current URL of the presentation. And the UA will need to retain this information anyway to implement the join algorithm [1].

However, until we have a use case for it (or some sample code using it), I'm okay dropping it from the spec.

[1] http://w3c.github.io/presentation-api/#joining-a-presentation-session

[schien]

The URL can be used by browser internally for the join algorithm but doesn't have to expose to web page (via WebIDL).

[tidoust]

If you need to define "internal properties" on some object in the spec and are wondering how best to phrase that (since it cannot be defined via WebIDL), I personally find the notational convention used in the EcmaScript spec useful (enclosing names in double square brackets [[ ]]).

See the Web Cryptography API that @mwatson2 co-edits for a usage example.

That's just FYI: there is no requirement to use that notation and adopting it would probably mean updating other parts of to use it consistently throughout the spec.

[markafoltz]

Let's just remove it from the IDL and keep it in the internal data structures required for the join algorithm.

[obeletski]

We do not have url attribute in IDL already now, that was the initial problem. We also already have that internal structure documented already [1] as "set of presentations that are currently known to the user agent" in the spec and join session and the rest of the algorithms are using it. What we can do is to convert that into definition in the spec, similar <dfn>list of available presentation displays</dfn>.

One more thing, we have a step in start session that Adds (S.url, S.id, S) to D, but we never clean up the D in any part of the spec. We possibly want to mention that somewhere.

[1] http://w3c.github.io/presentation-api/#common-idioms

[markafoltz]

@obeletski @schien I thought of a use case for this attribute. If a single controlling page has requested to start or join multiple presentations (each with their own URL) then it could result in simpler code to include the URL in the PresentationSession.

e.g. instead of

navigator.presentation.startSession(firstURL).then(handleSessionForFirstURL)
navigator.presentation.startSession(secondURL).then(handleSessionForSecondURL)

it would be

navigator.presentation.startSession(firstUrl).then(handleSession)
navigator.presentation.startSession(secondUrl).then(handleSession)

handleSession = function(session) {
  // Code common to all presentation sessions goes here

  // Now code specific to the presentation content
  if (session.url == firstUrl) ...
  else if (session.url == secondUrl) ...
}

Any thoughts?

[schien]

Web developers can still use bind to reuse the same handling function, so it doesn't gain much benefit if we don't provide the URL after redirection.

For example,

navigator.presentation.startSession(firstUrl).then(handleSession.bind(null, firstUrl))
navigator.presentation.startSession(secondUrl).then(handleSession.bind(null, secondUrl))

handleSession = function(url, session) {
  // Code common to all presentation sessions goes here

  // Now code specific to the presentation content
  if (url == firstUrl) ...
  else if (url == secondUrl) ...
}

[markafoltz]

@schien Okay, "when in doubt, leave it out." :)

@obeletski I'll rebase and merge your pull request if it otherwise looks okay.