Skip to content

Filling out the list of available presentation displays for start #387

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
tidoust opened this issue Dec 1, 2016 · 3 comments
Closed

Filling out the list of available presentation displays for start #387

tidoust opened this issue Dec 1, 2016 · 3 comments

Comments

@tidoust
Copy link
Member

tidoust commented Dec 1, 2016

Step 7. of the select a presentation display algorithm tells the user agent to monitor the list of available presentation displays. This is meant to fill out the list of available presentation displays, which needs to be non empty for the display selection to do something.

The monitoring algorithm fills out that list based on the contents of the set of presentation availability objects. Problem is that set is only filled out by the getAvailability algorithm.

In short, if an app calls start without first calling getAvailability, the monitoring algorithm will simply create an empty list of available presentation displays which would make start end up with a NotFoundError exception.

I guess the easiest way to fix that would be to have the selection algorithm set the presentation display availability right before current step 7, as done in getAvailability. Something like:

  1. If the presentation display availability for presentationRequest is null, then:
  • Set the presentation display availability for presentationRequest to a newly created PresentationAvailability object, and let A be that object.
  • Set the value property of A as follows:
    1. false if the list of available presentation displays is empty.
    2. true if there is at least one available presentation display for some member of presentationUrls. That is, there is an entry (presentationUrl, display) in the list of available presentation displays for some presentationUrl in presentationUrls.
    3. false otherwise.
  • Create a tuple (A, presentationUrls) and add it to the set of presentation availability objects.
  1. If the user agent is not monitoring the list of available presentation displays, run the steps to monitor the list of available presentation displays in parallel.

Now, in theory, there should be no reason to introduce PresentationAvailability objects in start. Oh well...
@tidoust
Copy link
Member Author

tidoust commented Dec 1, 2016

Hmm, a better fix might be to complete the monitoring algorithm with a step such as:

If there is a pending request to select a presentation display, run the following step:

  1. For each display in newDisplays, if display is an available presentation display for one of the presentation urls then run the following steps:
    • let presentationUrl be that presentation url
    • Insert a tuple (presentationUrl, display) into the list of available presentation displays, if no identical tuple already exists.

@markafoltz
Copy link
Contributor

We could just have a step in start() before 7 that creates an availability object for the request, and a cleanup step to remove the object. Then monitoring would run and insert any available displays into the list for the request URLs.

@markafoltz markafoltz mentioned this issue Dec 3, 2016
Closed
tidoust added a commit to tidoust/presentation-api that referenced this issue Dec 14, 2016
@tidoust
Issue w3c#387: Monitoring algo now takes pending request to start int…
97ee0f6 
…o account

Main changes:

- Prose similar to that used in the Web Bluetooth spec used for the garbage
collection note for the "presentation display availability" to clarify the
intent. We may want to adjust this text in w3c#391.
- Notion of "presentation availability promise" dropped. That promise is now
referenced in `getAvailability` as "an unsettled Promise from a previous call
to `getAvailability` on `presentationRequest`". This avoids having to be
explicit about garbage collection rules.
- Step that instructs the UA to run the monitoring algorithm no longer runs
"in parallel" (see w3c#381)
- Note added next to that step to clarify that the monitoring algorithm needs
to run again even if it is still running
- The monitoring algorithm now starts by making a shallow copy of the "set of
presentation availability objects" which gets completed with the right tuple if
there is a pending call to `start` (note there can be at most one such pending
call per controlling browsing context)
- Steps that update the `value` property adjusted to set the value directly for
`PresentationAvailability` objects that have not yet been exposed to ECMAScript
object. This is triggered by the following (new) problem: the `getAvailibility`
promise gets resolved with a `PresentationAvailability` object as soon as the
monitoring algorithm is done running, but the monitoring algorithm "queued a
task" to update the `value` property of `PresentationAvailability` objects. The
`value` property of the returned `PresentationAvailability` object would always
have been the initial value (`false` in most cases), even if the monitoring
algorithm had found an available display. Also, we probably do not want to fire
`change` events for properties that JS code has not yet been given any chance
to read. Here as well, we may want to adjust this text in w3c#391.
- The initial `value` of newly created `PresentationAvailability` objects is
now always `false`. There should be no need to set it to `true` given that the
monitoring algorithm refreshes that value right after that (and given the
previous fix).
- I added a note next to the monitoring algorithm to clarify that a user agent
may interrupt and re-run the algorithm to group requests, which seems like a
possible optimization.
tidoust added a commit to tidoust/presentation-api that referenced this issue Dec 16, 2016
@tidoust
Issue w3c#387: Use availabilitySet in the monitoring algorithm
e14c2ec 
The variable is obviously useless if it is not referenced. This should have
been part of previous commit.
@markafoltz markafoltz mentioned this issue Dec 19, 2016
Merged
tidoust added a commit to tidoust/presentation-api that referenced this issue Dec 20, 2016
@tidoust
Issue w3c#387: drop "exposed to JS" and allow monitoring aggregation
4491260 
This commit drops the fuzzy "exposed to ECMAScript" wording in the monitoring
algorithm, and replaces it with a more common "initialized" concept. The notion
is clarified in an editorial note next to the step that uses it.

The editorial note that follows the monitoring algorithm was also complete to
mention that user agents may aggregate monitoring activities across browsing
contexts.
markafoltz added a commit that referenced this issue Dec 20, 2016
@markafoltz
Addreses Issue 387 (#395)
f2f4fee 
Addresses Issue #387: Well defined environment for nested contexts of the receiving browsing context
tidoust added a commit to tidoust/presentation-api that referenced this issue Dec 21, 2016
@tidoust
Issue w3c#387: Update notes with @mfoltzgoogle suggestions
db2e701
markafoltz pushed a commit that referenced this issue Dec 21, 2016
@tidoust @markafoltz
Issue #387: Monitoring algo takes pending request to start into accou…
0c800c5 
…nt (#392)

* Issue #387: Monitoring algo now takes pending request to start into account

Main changes:

- Prose similar to that used in the Web Bluetooth spec used for the garbage
collection note for the "presentation display availability" to clarify the
intent. We may want to adjust this text in #391.
- Notion of "presentation availability promise" dropped. That promise is now
referenced in `getAvailability` as "an unsettled Promise from a previous call
to `getAvailability` on `presentationRequest`". This avoids having to be
explicit about garbage collection rules.
- Step that instructs the UA to run the monitoring algorithm no longer runs
"in parallel" (see #381)
- Note added next to that step to clarify that the monitoring algorithm needs
to run again even if it is still running
- The monitoring algorithm now starts by making a shallow copy of the "set of
presentation availability objects" which gets completed with the right tuple if
there is a pending call to `start` (note there can be at most one such pending
call per controlling browsing context)
- Steps that update the `value` property adjusted to set the value directly for
`PresentationAvailability` objects that have not yet been exposed to ECMAScript
object. This is triggered by the following (new) problem: the `getAvailibility`
promise gets resolved with a `PresentationAvailability` object as soon as the
monitoring algorithm is done running, but the monitoring algorithm "queued a
task" to update the `value` property of `PresentationAvailability` objects. The
`value` property of the returned `PresentationAvailability` object would always
have been the initial value (`false` in most cases), even if the monitoring
algorithm had found an available display. Also, we probably do not want to fire
`change` events for properties that JS code has not yet been given any chance
to read. Here as well, we may want to adjust this text in #391.
- The initial `value` of newly created `PresentationAvailability` objects is
now always `false`. There should be no need to set it to `true` given that the
monitoring algorithm refreshes that value right after that (and given the
previous fix).
- I added a note next to the monitoring algorithm to clarify that a user agent
may interrupt and re-run the algorithm to group requests, which seems like a
possible optimization.

* Issue #387: Use availabilitySet in the monitoring algorithm

The variable is obviously useless if it is not referenced. This should have
been part of previous commit.

* Issue #387: drop "exposed to JS" and allow monitoring aggregation

This commit drops the fuzzy "exposed to ECMAScript" wording in the monitoring
algorithm, and replaces it with a more common "initialized" concept. The notion
is clarified in an editorial note next to the step that uses it.

The editorial note that follows the monitoring algorithm was also complete to
mention that user agents may aggregate monitoring activities across browsing
contexts.

* Issue #387: Update notes with @mfoltzgoogle suggestions
@markafoltz markafoltz mentioned this issue Dec 21, 2016
Closed
@markafoltz
Copy link
Contributor

Should be addressed by PR #387.

@markafoltz markafoltz mentioned this issue Dec 21, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tidoust @markafoltz