-
Notifications
You must be signed in to change notification settings - Fork 39
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.
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
PresentationRequest.getAvailability() could always return a new Promise #507
Comments
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. |
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.
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. |
Thanks for looking into the TAG guidance and documenting the rationale here. I agree with your assessment. |
The steps for
getAvailability()
have an optimization (?) to return (sometimes) a pre-existingPromise
from a previous call togetAvailability()
.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 NFCopen()
in Web USBrequestPort()
in Web SerialwatchAdvertisements()
in Web BluetoothThose 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.
The text was updated successfully, but these errors were encountered: