W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 13 May 2014 19:39:07 +0000
To: public-script-coord@w3.org
Message-ID: <bug-25457-3890-FQR8QcjJwi@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457

--- Comment #14 from Dan Beam <dbeam@chromium.org> ---
(In reply to Domenic Denicola from comment #13)
> I'm sorry, I still don't understand.
> 
> Functions can either return values or throw exceptions. Async functions can
> either return fulfilled promises or return rejected promises.
> 
> When you throw an exception, you can throw anything, e.g. `throw 5`. This is
> bad practice though, and you generally try to throw things that are
> `instanceof Error` so that e.g. consumers can get stack traces.
> 
> Similarly, when you reject a promise with an exception, you can reject with
> anything, e.g. `return Promise.reject(5)`. Again this is bad practice, and
> you should generally reject with things that are `instanceof Error`.
> 
> There are no "restrictions" in the promise case that do not appear for every
> function, ever: your function can either succeed or fail, and if it fails,
> it _should_ do so using Error instances.
> 
> Why are these semantics---which are fairly basic to JavaScript, and indeed
> to most imperative languages---too restrictive to implement
> requestAutocomplete?

In this analogy, requestAutocomplete never throws and therefore never rejects. 
We'd basically just be using Promises as a callback (which one can already do
with events).

Though I did not expect rAc to be resolved if the form was not filled (see my
original email[1]), perhaps my understanding of Promise semantics was bad.  I
do think authors would be mildly confused as to when they'd ever need a
.catch() (just like authors are unaware of when to use try {} catch() {}
without some strong way of knowing an interface throws [like in Java]).

esprehn@ worked pretty hard to streamline the default success case (e.g. static
validation + "invalid" to omit checkValidity() from success callback), so
adding a way to invoke rAc like this:

  promise.then(function(result) {
    if (result == 'success') {
      // success! submit form or fancy AJAX
    } else if (result == 'cancel') {
      // user canceled, maybe redirect?
    } else if (result == 'invalid') {
      // 1+ inputs are invalid, fix this somehow
    } else if (result == 'disabled') {
      // something bad happened, run for the hills
    }
  });

is about as (or less) appealing to me than the current code:

  form.onautocomplete = function() { /* success! submit form or fancy AJAX */
};

if the author only cares about the success case, and

  form.onautocompleteerror = function(error) {
    if (error.reason == 'cancel') {
      // user canceled, possibly redirect or something
    } else if (error.reason == 'invalid') {
      // 1+ inputs are invalid, fix this somehow
    } else if (error.reason == 'disabled') {
      // something bad happened, run for the hills
    }
  };

if they care about errors (in some cases, e.g. donations, they may not care
about errors).

esprehn@: thoughts on the new Promises code example?


(In reply to Joshua Bell from comment #9)
> I'm not familiar with the feature, but looking at the reasons listed in #c3,
> most of them do look to me like cases for which an exception would be thrown
> if the API were synchronous:
> 
>   Case: invoked on an insecure page (e.g. non-HTTPS)
>   Case: invoked without processing a user gesture
>   Case: no payment-specific [autocomplete] types were found in form controls
>   Case: invoked on <form autocomplete="off">
>   Case: invoked on <form> not in a frame (e.g. in a document fragment)
> 
> i.e. the developer didn't read the fine print, and the page has bugs. Best
> thing to do is log those errors back to the server and fix the page.

Most "disabled" cases are developer error, but not all.

The spec allows failure with a "disabled" reason if "the user has disabled this
feature for this form's Document's origin".  Chrome does not currently do this,
but has in the past.  We used to also deny invocation from a frame.

Also, some extensions add autocomplete="off" to <form>s (basically attempting
to turn off Autofill), which can cause this error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 13 May 2014 19:39:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:21 UTC