Steps that re-use objects should specify the relevant settings object/Javascript Realm #391
Comments
tidoust
added a commit
to tidoust/presentation-api
that referenced
this issue
Dec 14, 2016
…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.
markafoltz
pushed a commit
that referenced
this issue
Dec 21, 2016
…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
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are three algorithms that re-use objects:
getAvailabilityre-uses aPromiseand aPresentationAvailabilityreconnectre-uses aPresentationConnectionnavigator.presentation.receiver.connectionListre-uses aPromiseandPresentationConnectionListThese steps need to specify the relevant settings object / Realm, instead of the current settings object/realm. Otherwise, badness ensues when they are invoked or accessed across browsing contexts. See [1] for an example of this with
navigator.getBattery().[1] https://www.w3.org/TR/html52/webappapis.html#realms-settings-objects-global-objects
The text was updated successfully, but these errors were encountered: