[Bug 25457] Adding "AutocompleteError" to error names table

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 the QA Contact for the bug.

Received on Saturday, 3 May 2014 03:38:08 UTC