One last one :) My apologies for not seeing that before as well!

getAvailability is the only algorithm that sets the presentation display availability. That algorithm also creates (and never resets) the presentation availability promise.

The presentation display availability will always be null the first time getAvailability is called so condition in step 7 that checks on the presentation display availability will always evaluate to false. The presentation availability promise will always be set in subsequent calls to getAvailability, meaning that the algorithm will stop at step 2, return that promise, and never reach step 7.

In short, unless I missed something, I believe that step (and substeps) can be dropped.

This did not happen before because there was no such thing as a "presentation availability promise".

Sorry, I don't follow. The availability will be set to true if there is a display in the list of available presentation displays that is compatible, found earlier by the monitoring steps.

Well, the step 7 I was looking at is now step 6: "If the presentation display availability for presentationRequest is not null, then: [...]".

The problem boils down to whether the user agent can reset the presentation availability promise at some point in time, as I alluded to in a comment on PR #390: #390 (comment)

If it cannot (which is how I read the current algorithm), then the promise will be set in any further call to getAvailability. That means any further call will stop at step 2, and so step 6. is useless.

Now, if the user agent can garbage collect the presentation availability promise once it is settled and/or no longer referenced, then step 6. remains useful!

That step would also be useful if start can set the presentation display availability, as envisioned in PR #390.

Okay, I am starting to understand what you are getting at. Thanks for your patience.

The question is whether the availability promise/object is tied to the lifetime of the request that created them, which means they are created once and only once. Or, if they can be GCed independently from the request and recreated later.

I believe the intention is that the developer can use the lifetime of the availability object to control when the browser is engaged in continuous monitoring of displays, and responsible usage would discard the object when the site isn't offering a UX to start presentation.

We didn't add a specific discard() or dispose() API for this; that doesn't seem to be a common Web idiom.

Unless we go that route, GC should be able to discard the availability object/promise independent of the request, and in that case, we would need to recreate them if getAvailability() is called again.

@schien Does that make sense? Any other input?

Okay, I am starting to understand what you are getting at. Thanks for your patience.

No problem, I can tell my comments are getting more and more convoluted :)

Unless we go that route, GC should be able to discard the availability object/promise independent of the request, and in that case, we would need to recreate them if getAvailability() is called again.

OK, this issue becomes moot in that case.
See proposal in #390 (comment) to clarify GC expectations.

I believe this should be addressed by PR #387.