[Webkit-unassigned] [Bug 258911] New: [WebAuthn] .catch() for conditional mediation is not passed the abortreason that was thrown

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=258911

            Bug ID: 258911
           Summary: [WebAuthn] .catch() for conditional mediation is not
                    passed the abortreason that was thrown
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sweeden at au1.ibm.com

Consider I have a WebAuthn conditional mediation call (with appropriate abortController established), with a catch block such as:

navigator.credentials.get(publicKey)
.then((assertion) => {})
.catch((error) => {});

This bug is in relation to the type and value of "error" above, when the call is aborted with something like:
abortController.abort("AbortError");


According to step 3 of section 2.5.1 of the credential management API (see https://w3c.github.io/webappsec-credential-management/#algorithm-request) if the autofill navigator.credentials.get call is aborted, then the promise should be rejected "with options.signal’s abort reason". According to this reference (https://dom.spec.whatwg.org/#abortsignal-abort-reason) abort reason is "a JavaScript value" - though it is not entirely clear what that means.

The way I read it, I would have expected the value of "error" in the catch block to be the string "AbortError" - ie. what is thrown as the reason in the call to abort(), and this is indeed what I see in Chrome.

In Safari, typeof(error) returns "object", so the thing passed to the rejected promise is not the plain string abort reason.

This lack of consistency makes it difficult to write portable code in the catch block of mediated WebAuthn calls. 

I'm opening this defect to seek clarification on whether or not this is seen by the WebKit team as a bug, and if not, what the reasoning is.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230706/dd399a8b/attachment.htm>