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: Thu, 08 May 2014 01:07:18 +0000
To: public-script-coord@w3.org
Message-ID: <bug-25457-3890-n7DFhQXxuS@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457

Joshua Bell <jsbell@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsbell@google.com

--- Comment #9 from Joshua Bell <jsbell@google.com> ---
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.

Not sure about this one:

  Case: a <form> control fails static validation after being filled

The last one is interesting:

  Case: user cancels flow

i.e. user denied permission. We should probably be very consistent across the
web platform for that case for requestXXX() APIs.

I don't see "user agent policy" on the list e.g. "feature disabled"; at least
for Service Worker we're treating that as a rejection.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 8 May 2014 01:07:19 UTC

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