PresentationRequest.getAvailability() could always return a new Promise

[markafoltz]

The steps for getAvailability() have an optimization (?) to return (sometimes) a pre-existing Promise from a previous call to getAvailability().

However this isn't consistent with other specs that always return a new Promise when starting an asynchronous action on another device:

• scan() in Web NFC
• open() in Web USB
• requestPort() in Web Serial
• watchAdvertisements() in Web Bluetooth

Those are a few examples pulled by skimming other specs, there are likely more.

The Promise-caching also produces some implementation complexity because the browser must sometimes store the Promise like a property of the request, and sometimes allocate a new object and pass it directly to script.

It would be simpler to implement, and more consistent with other specs, to always return a new Promise here.

[markafoltz]

This Blink code review has some additional conversation about why this is simpler to implement (at least in Blink.) The CL was abandoned until the spec could be updated with this behavior.

[markafoltz]

I reviewed the discussion in the TAG guidance and now believe that returning a new Promise is the right thing to do for two reasons.

1. Because browsers can become able or unable to monitor the list of presentation displays in the background, the getAvailability() method is a "state transition" case and not a "one time asynchronous function" case in the TAG guidance.

2. With the current algorithm, an app will have no way to monitor availability if the browser becomes able to monitor presentation displays (when it could not before) because the previously-rejected Promise will always be returned. The only way would be to create a new but identical PresentationRequest, which is not very intuitive.

To implement the full "state transition" guidance and conditionally return existing Promises would add significant complexity to the spec and implementations, because the browser would need to track all of the reasons why monitoring was possible (or not) continuously, and signal the API to behave accordingly on state transitions. In Chrome, there are at least 5-6 reasons I can think of, and some that Chrome can't even know about until it tries to query for compatible devices. I don't support adding this requirement to implementations.

[anssiko]

Thanks for looking into the TAG guidance and documenting the rationale here. I agree with your assessment.