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.