-
Notifications
You must be signed in to change notification settings - Fork 180
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
Should the WebAuth API have a cancel() method? #380
Comments
I believe @jakearchibald is working on promise cancellation in the context of |
We plan to represent cancellation by rejecting with an |
It seems that this puts good UI at the mercy of every web developer. This seems wrong. The UA could for example cancel operations when a tab is occluded. But it seems like that would not require a Javascript method for the webpage to do so? |
see also #316 "Define what happens when the Document loses focus" |
I see. Right, the browser could certainly handle losing focus. |
@mikewest boiled down the I believe this is a pretty good fit for our use-case - if we decided this was something we needed to do. |
The PR moved to whatwg/dom#437. |
@jyasskin notes on call today that the web platform folks are working on a general cancellation mech and it will likely be another option -- @AngeloKai sez he'll talk with their fetch folks to see what the status is on what's mentioned in #380 (comment) Also, the relevant whatwg/dom PR is now this one: whatwg/dom#437 |
Looks like this has solidified into https://dom.spec.whatwg.org/#aborting-ongoing-activities. |
It sure has! Is it suitable for what you need? |
@mikewest The PR looks enough for this need. Looking through the PR, it looks like we still need to add a few sentences in our algorithm section about how we accept the AbortSignal. |
Because the issue has to do with changing the algorithm and this issue would impact cornercase user experience, I am moving the issue back to WD07. |
Closed by #544 |
Hey gang,
The spec details an authenticatorCancel method, but the client doesn't necessarily know when to invoke it. We have seen a couple scenarios where not having a way to cancel an existing authenticator operation from Javascript might present an undesirable user experience.
For example, having multiple tabs that are attempting operations and losing focus on one. The user opens two registration tabs. The device will blink until it receives two taps.
Since promises aren't themselves cancelable, it seems that a cancel() method is the best option - assuming these use cases are concerning enough to warrant one. (We're not entirely convinced that they are). We also briefly considered having smaller timeouts, say, 10 seconds, but this presents problems for bluetooth authenticators.
Thoughts?
The text was updated successfully, but these errors were encountered: