Skip to content

Commit 97ee0f6

Browse files
committed
Issue w3c#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 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.
1 parent 200951c commit 97ee0f6

File tree

1 file changed

+81
-59
lines changed

1 file changed

+81
-59
lines changed

index.html

Lines changed: 81 additions & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -1117,10 +1117,10 @@

11171117
abort these steps.
11181118
li>
11191119
<li>If there is already an unsettled <a>Promisea> from a previous
1120-
call to <code>startcode> on any <code>PresentationRequestcode>
1121-
in the same <a>controlling browsing contexta>, return a new
1122-
<a>Promise</a> rejected with an <a>OperationErrora> exception and
1123-
abort all remaining steps.
1120+
call to <a for="PresentationRequest">starta> on any
1121+
<a>PresentationRequesta> in the same <a>controlling browsing
1122+
context</a>, return a new <a>Promisea> rejected with an
1123+
<a>OperationErrora> exception and abort all remaining steps.
11241124
li>
11251125
<li>Let <var>Pvar> be a new <a>Promisea>.
11261126
li>
@@ -1542,6 +1542,11 @@

15421542
any <a>available presentation displaya> for at least one of the
15431543
<a>presentation request URLsa> of the request.
15441544
p>
1545+
<p>
1546+
The <a>presentation display availabilitya> for a presentation
1547+
request is eligible for garbage collection when no ECMASCript code
1548+
can observe the <code>PresentationAvailabilitycode> object.
1549+
p>
15451550
<p>
15461551
If the <a>controlling user agenta> can <a>monitor the list of
15471552
available presentation displaysa> in the background (without a
@@ -1564,15 +1569,6 @@

15641569
<h4>
15651570
The set of presentation availability objects
15661571
h4>
1567-
<p>
1568-
Each <code>PresentationRequestcode> has a <a>presentation
1569-
availability promisea> and a <a>presentation display
1570-
availabilitya>, which are initially set to <code>nullcode>. The
1571-
<dfn>presentation availability promisedfn> for a
1572-
<code>PresentationRequestcode> is a <code>Promisecode> object
1573-
that <a data-lt="resolve">resolvesa> to the <a>presentation
1574-
display availabilitya> for the request.
1575-
p>
15761572
<p>
15771573
The <a>user agenta> MUST keep track of the <dfn>set of
15781574
presentation availability objectsdfn> created by the
@@ -1677,19 +1673,15 @@

16771673
li>
16781674
ol>
16791675
li>
1680-
<li>If the <a>presentation availability promisea> for
1681-
<code>presentationRequestcode> is not <code>nullcode>, return
1682-
the <code>presentationRequestcode> object's <a>presentation
1683-
availability promisea> and abort these steps.
1676+
<li>If there is an unsettled <a>Promisea> from a previous call to
1677+
<a for="PresentationRequest">getAvailabilitya> on
1678+
<code>presentationRequestcode>, return that <a>Promisea> and
1679+
abort these steps.
16841680
li>
1685-
<li>Otherwise, set the <code>presentationRequestcode> object's
1686-
<a>presentation availability promisea> to a newly created <code>
1687-
Promisecode> object and set <var>Pvar> to this
1688-
<code>Promisecode>.
1681+
<li>Otherwise, let <var>Pvar> be a new <a>Promisea>.
16891682
li>
1690-
<li>Return the <code>presentationRequestcode> object's
1691-
<a>presentation availability promisea>, but continue running
1692-
these steps <a>in parallela>.
1683+
<li>Return <var>Pvar>, but continue running these steps <a>in
1684+
parallela>.
16931685
li>
16941686
<li>If the user agent is unable to continuously <a>monitor the list
16951687
of available presentation displaysa> in the background, but can
@@ -1717,34 +1709,22 @@

17171709
li>
17181710
<li>Set the <a>presentation display availabilitya> for
17191711
<var>presentationRequestvar> to a newly created
1720-
<code>PresentationAvailabilitycode> object, and let <var>Avar>
1721-
be that object.
1712+
<a>PresentationAvailabilitya> object, and let <var>Avar> be
1713+
that object.
17221714
li>
1723-
<li>Set the <code>valuecode> property of <var>Avar> as follows:
1724-
<ol>
1725-
<li>
1726-
<code>falsecode> if the <a>list of available presentation
1727-
displaysa> is empty.
1728-
li>
1729-
<li>
1730-
<code>truecode> if there is at least one <a>available
1731-
presentation displaya> for some member of
1732-
<var>presentationUrlsvar>. That is, there is an entry
1733-
<var>(presentationUrl, display)var> in the <a>list of
1734-
available presentation displaysa> for some
1735-
<var>presentationUrlvar> in <var>presentationUrlsvar>.
1736-
li>
1737-
<li>
1738-
<code>falsecode> otherwise.
1739-
li>
1740-
ol>
1715+
<li>Set the <code>valuecode> property of <var>Avar> to
1716+
<code>falsecode>.
17411717
li>
17421718
<li>Create a tuple <em>(<var>Avar>,
17431719
<var>presentationUrlsvar>)em> and add it to the <a>set of
17441720
presentation availability objectsa>.
17451721
li>
17461722
<li>Run the algorithm to <a>monitor the list of available
1747-
presentation displaysa> <a>in parallela>.
1723+
presentation displaysa>.
1724+
<div class="note">
1725+
This algorithm needs to run even if it is already running to
1726+
pick up the tuple created in the previous step.
1727+
div>
17481728
li>
17491729
<li>
17501730
<a>Resolvea> <var>Pvar> with <var>Avar>.
@@ -1761,11 +1741,31 @@

17611741
"PresentationRequest" data-lt="start">select a presentation
17621742
displaya>, the <a>user agenta> MUST <dfn>monitor the list of
17631743
available presentation displaysdfn> by running the following
1764-
steps.
1744+
steps:
17651745
p>
17661746
<ol link-for="PresentationAvailability">
1767-
<li>Set the <a>list of available presentation displaysa> to the
1768-
empty list.
1747+
<li>Let <var>availabilitySetvar> be a shallow copy of the <a>set
1748+
of presentation availability objectsa>.
1749+
li>
1750+
<li>If there is a pending request to <a for="PresentationRequest"
1751+
data-lt="start">select a presentation displaya> for a
1752+
<a>PresentationRequesta> and if the <a>PresentationRequesta>'s
1753+
<a>presentation display availabilitya> is <code>nullcode>, then
1754+
run the following substeps:
1755+
<ol>
1756+
<li>Let <var>Avar> be a newly created
1757+
<a>PresentationAvailabilitya> object.
1758+
li>
1759+
<li>Set the <var>valuevar> property of <var>Avar> to <code>
1760+
falsecode>.
1761+
li>
1762+
<li>Create a tuple <em>(<var>Avar>,
1763+
<var>presentationUrlsvar>)em> where
1764+
<var>presentationUrlsvar> is the <a>PresentationRequesta>'s
1765+
<a>presentation request URLsa> and add it to the <a>set of
1766+
presentation availability objectsa>.
1767+
li>
1768+
ol>
17691769
li>
17701770
<li>Let <var>newDisplaysvar> be an empty list.
17711771
li>
@@ -1776,6 +1776,9 @@

17761776
<li>Retrieve <a>presentation displaysa> (using an implementation
17771777
specific mechanism) and set <var>newDisplaysvar> to this list.
17781778
li>
1779+
<li>Set the <a>list of available presentation displaysa> to the
1780+
empty list.
1781+
li>
17791782
<li>For each member <em>(<var>Avar>,
17801783
<var>availabilityUrlsvar>)em> of the <a>set of presentation
17811784
availability objectsa>, run the following steps:
@@ -1806,30 +1809,49 @@

18061809
ol>
18071810
li>
18081811
<li>If <var>previousAvailabilityvar> is not equal to
1809-
<var>newAvailabilityvar>, then <a>queue a taska> to run the
1810-
following steps:
1812+
<var>newAvailabilityvar>, then run the following steps:
18111813
<ol>
1812-
<li>Set <var>Avar>'s <a>valuea> property to
1813-
<var>newAvailabilityvar>.
1814+
<li>If <var>Avar> has already been exposed to ECMAScript
1815+
code, then <a>queue a taska> to run the following steps:
1816+
<ol>
1817+
<li>Set <var>Avar>'s <a>valuea> property to
1818+
<var>newAvailabilityvar>.
1819+
li>
1820+
<li>
1821+
<a>Fire a simple eventa> named <a>changea> at
1822+
<var>Avar>.
1823+
li>
1824+
ol>
18141825
li>
1815-
<li>
1816-
<a>Fire a simple eventa> named <a>changea> at
1817-
<var>Avar>.
1826+
<li>Otherwise, set <var>Avar>'s <a>valuea> property to
1827+
<var>newAvailabilityvar>.
18181828
li>
18191829
ol>
18201830
li>
18211831
ol>
18221832
li>
18231833
ol>
1834+
<div class="note">
1835+
Multiple requests to run the algorithm to <a>monitor the list of
1836+
available presentation displaysa> may occur at once, e.g., due to
1837+
calls to <a for="PresentationRequest">getAvailabilitya> and
1838+
<a for="PresentationRequest">starta>. The <a>user agenta> may
1839+
run such requests in parallel, serialize them, or interrupt the
1840+
algorithm if it is before or at step 5 and run it again to group
1841+
requests.
1842+
div>
18241843
<p>
1825-
When a <a>PresentationAvailabilitya> object is no longer alive
1826-
(i.e., is eligible for garbage collection), the <a>user agenta>
1827-
SHOULD run the following steps:
1844+
When a <a>presentation display availabilitya> object is no longer
1845+
alive (i.e., is eligible for garbage collection), the <a>user
1846+
agenta> SHOULD run the following steps:
18281847
p>
18291848
<ol>
1849+
<li>Let <var>Avar> be the newly deceased
1850+
<a>PresentationAvailabilitya> object
1851+
li>
18301852
<li>Find and remove any entry <em>(<var>Avar>,
18311853
<var>availabilityUrlvar>)em> in the <a>set of presentation
1832-
availability objectsa> for the newly deceased <var>Avar>.
1854+
availability objectsa>.
18331855
li>
18341856
<li>If the <a>set of presentation availability objectsa> is now
18351857
empty and there is no pending request to <a for=

0 commit comments

Comments
 (0)