- From: <bugzilla@jessica.w3.org>
- Date: Sat, 03 May 2014 03:38:06 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457
Dan Beam <dbeam@chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |esprehn@gmail.com,
| |estade@chromium.org,
| |ian@hixie.ch
--- Comment #3 from Dan Beam <dbeam@chromium.org> ---
Boris Zbarsky asked that I check with public-script-coord@ (CC'd) regarding
minting new DOMExceptions[1]. I’m proposing a new AutocompleteError type
that’d be used when rejecting a Promise returned by
`form.requestAutocomplete()`[2][3].
To quote the WebIDL spec[4]:
"""
Authors of future Web platform specifications should not mint new IDL
exceptions but instead should use DOMException and distinguish different kinds
of exceptions by their type and not by an integer code. The type will be
exposed in ECMAScript using a "name" property on the exception object. One
valid reason to mint new IDL exceptions is if additional exception fields are
required. If a predefined exception matches the meaning of the exception to be
thrown, it should be used in preference to minting an exception type.
"""
My proposed AutocompleteError would have a new exception field and look
something like this (excuse the [probably wrong] IDL):
exception AutocompleteError : DOMException {
// code = 0
// name = "AutocompleteError"
const DOMString reason;
};
The reason field would be the same as the AutocompleteErrorEvent.reason[5]
dispatched before the Promise is rejected. Current reason values are:
"disabled" => flow was not run (generally because of developer error)
"cancel" => flow was started but the user cancelled
"invalid" => flow succeeded but invalid data was received
These values are already spec'd in HTML, implemented in Chrome (Firefox in
progress[6]), and used by some sites.
Conversely, here's my best attempt at reusing existing error names[7] for
Chrome's present implementation:
Case: user cancels flow
Reason: "cancel"
Name: AbortError
Case: invoked on an insecure page (e.g. non-HTTPS)
Reason: "disabled"
Name: SecurityError
Case: invoked without processing a user gesture
Reason: "disabled"
Name: InvalidStateError?
Case: no payment-specific [autocomplete] types were found in form controls
Reason: "disabled"
Name: NotSupportedError?
Case: invoked on <form autocomplete="off">
Reason: "disabled"
Name: NoModificationAllowedError?
Case: invoked on <form> not in a frame (e.g. in a document fragment)
Reason: "disabled"
Name: WrongDocumentError?
Case: a <form> control fails static validation after being filled
Reason: "invalid"
Name: InvalidModificationError or InvalidStateError?
I believe that reusing existing terminology could make the API more convoluted
(e.g. does a "cancel" reason mean the same thing as an AbortError?). Chrome
already logs detailed failure messages to the developer console for testing (as
encouraged by the spec), so I think differentiating failures at runtime wont be
very useful (most errors are likely to occur only while adding this feature to
a site).
Thoughts?
--
Dan Beam
dbeam@chromium.org
[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/254173.html
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#dom-form-requestautocomplete
[3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/254142.html
[4] http://www.w3.org/TR/WebIDL/#idl-exceptions
[5]
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autocompleteerrorevent
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=939351
[7] http://w3c.github.io/dom/#error-names-0
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Saturday, 3 May 2014 03:38:07 UTC