Enums that does not throw? #893
Comments
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): |
|
Yes, some HTML IDL attributes e.g. |
|
IDL does not throw for enums passed to setters. It only does so for methods and constructors. @jcjones could you elaborate a bit on w3c/webauthn#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 All uses of WebAuthn are through passing dictionaries to the methods 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. |
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 |
|
Just found that |
|
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 |
Fix the naming of the IDL members to match the naming-convention documented in [0]. This is a breaking change, so I intend to cherry-pick this CL after landing into M112 to avoid breaking the feature [1] shipping in that release in stable. (There will be a breaking change in other channels, but I believe that should be OK, especially given that the M112 feature code only landed recently and shouldn't have any usage yet). Also, as part of this change, stop throwing exceptions for unsupported enum fields -- ignore them instead. This lets FLEDGE API users use new fields as they are introduced, without needing to provide feature detection APIs, or require checking browser versions. This CL doesn't use the "enum" WebIDL type because: 1) "enum" doesn't support forward compatibility as described above -- it always throws for unsupported fields [2]. 2) The Chromium WebIDL bindings for enum have some backward compatibility issues -- you cannot have an enum with both "camelCase" and "dash-naming", since "fooBar" and "foo-bar" both result in kFooBar in the generated C++ enum, causing a compile error due to the duplication. So, if you already shipped "fooBar", you cannot also support "foo-bar" as an alias without switching to some other WebIDL type, like one of the string types. [0] https://webidl.spec.whatwg.org/#idl-enums [1] crrev.com/c/4219559, crrev.com/c/4261810 [2] whatwg/webidl#893 Change-Id: Id52412b7101837a5923359a927584da2d4c7d630 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4295454 Commit-Queue: Caleb Raitto <caraitto@chromium.org> Reviewed-by: Russ Hamilton <behamilton@google.com> Cr-Commit-Position: refs/heads/main@{#1111168}
group-by-origin should be used instead to match the naming documented in [0]. Also, switch executionMode to "USVString" to avoid the compatibility issue with "enum" described in [1]. [0] https://webidl.spec.whatwg.org/#idl-enums [1] whatwg/webidl#893
|
For integers we have |
w3c/webauthn@a133711 (w3c/webauthn#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:
Should this be supported in IDL level? Is there any other specification that does the same thing?
The text was updated successfully, but these errors were encountered: