webidl
webidl copied to clipboard
whatwg
Enums that does not throw?
https://github.com/w3c/webauthn/commit/a133711055b3b13c700fe2ea2acd62fe749a3f74 (https://github.com/w3c/webauthn/pull/1392)
Web Authentication just dropped their uses of enums because it's not forward compatible; older implementation throws when passing a newly added enum value. They now use DOMString and have proses to ignore unknown enum values:
Client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist.
Should this be supported in IDL level? Is there any other specification that does the same thing?
Is there any other specification that does the same thing?
I think this is what pretty much every attribute reflecting an “enumerated” HTML content attribute does. The Web IDL attributes are typed as DOMString, and there are additional rules for their behavior defined in HTML, though many of these cases are a bit more complex (the validity of tokens is potentially dynamic vis a vis other state, if I understand right):
IDL does not throw for enums passed to setters. It only does so for methods and constructors.
@jcjones could you elaborate a bit on https://github.com/w3c/webauthn/issues/1376? It's a little surprising to see specifications deviate from the platform norms.
Sure, @annevk: The bug was https://bugzilla.mozilla.org/show_bug.cgi?id=1573245 for the webcompat issue with Chrome. When they added the enum type and began using it, Gecko threw Uncaught (in promise) TypeError: CredentialsContainer.get: 'cable' (value of 'transports' member of PublicKeyCredentialDescriptor) is not a valid value for enumeration AuthenticatorTransport. while parsing the scripts.
All uses of WebAuthn are through passing dictionaries to the methods navigator.credentials.get or navigator.credentials.create, which presumably is why they throw.
It sounds like it would have been more future-proof if Credentials Management had instead returned an interface which could have been manipulated with setters, and had some sort of execute method.
Thanks, I can see how this might be useful for certain dictionaries, although normally I'd expect the caller to do some kind of feature testing. For IDL we should probably wait until more use cases show up around methods/dictionaries.
@annevk
IDL does not throw for enums passed to setters. It only does so for methods and constructors.
Thanks for clarifying/correcting this. I’d never noticed the special casing in create-an-attribute-setter and had assumed HTML not using IDL enums for reflected content attributes was about not-throwing. Is the use of DOMString for these in HTML just cause of the invalid/missing value defaults + sometimes-stateful valid value sets?
@bathos I think it's also that HTML has to deal with equivalent setAttribute() calls and those will always take DOMString.
Just found that DataTransfer#dropEffect/DataTransfer#effectAllowed also have the same ignoring behavior.
linking to the similar request in #491 for record keeping
Should we close either one?
For developing FLEDGE [0], we'd be interested in enums that don't throw, since we have several "enums" that will grow as we add new functionality. Often, feature detection seems like it needn't be necessary, since ignoring unsupported enum fields on older browsers seems sufficient for our use-cases?
For now, due to this issue, we're using strings instead of enums.
[0] https://github.com/WICG/turtledove/blob/main/FLEDGE.md
For integers we have Clamp and EnforceRange extended attributes to control throwing or changing the value. If specs want to use enums but not throw it seems useful to add an extended attribute to opt in to no throwing. Should it only work when setting a default value, where unknown values are converted to the default value?
