When is the first presentation connection created in the receiving browsing context? #254
Labels
Comments
18 tasks
tidoust
added a commit
to tidoust/presentation-api
that referenced
this issue
Apr 15, 2016
Getting the connectionList attribute now returns the same PresentationConnectionList instance, and only resolves the promise when the set of presentation controllers is non empty (as things stood, the use of a Promise was useless). The commit also drops the step that instructed the receiving user agent to start monitoring incomping presentation connections if not already started. This is done in the "starting a presentation" algorithm, no need to repeat it here.
|
Closed by PR #277. |
markafoltz
pushed a commit
that referenced
this issue
May 26, 2016
Getting the connectionList attribute now returns the same PresentationConnectionList instance, and only resolves the promise when the set of presentation controllers is non empty (as things stood, the use of a Promise was useless). The commit also drops the step that instructed the receiving user agent to start monitoring incomping presentation connections if not already started. This is done in the "starting a presentation" algorithm, no need to repeat it here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The spec does not say anything about the creation of the first presentation connection in the set of presentations on the receiving side.
When the receiving browsing context is created, the
PresentationReceiversingleton is created as well. Should the receiving user agent also create the firstPresentationConnectioninstance at the same time? Also, what should its presentation connection state be?The text was updated successfully, but these errors were encountered: