Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
On 4/25/14, 12:06 AM, Dan Beam wrote: interface AutocompleteError : DOMException { DOMException isn't an interface as currently proposed. In general, please check with public-script-coord before minting new exception types; there's been a lot of discussion on that issue recently. -Boris
Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
On Wed, Apr 16, 2014 at 6:59 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > > From: db...@google.com [mailto:db...@google.com] On Behalf Of Dan Beam > > > So just pass no argument at all (i.e. arguments.length == 0)? I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). > > It's equivalent, both for promises and for return values of functions. Both `new Promise(resolve => resolve())` and `new Promise(resolve => resolve(undefined))` give a promise whose fulfillment value is `undefined`. In this sense `resolve` behaves like all non-evil JavaScript functions, where evil is defined as "checking `arguments.length`" ;) > I've seen only positive feedback on this thread, so I've started implementing in Blink. Regarding the rejection argument: requestAutocomplete() can fail in a way that doesn't map intuitively to the current DOMException names (e.g. the invoking has autocomplete="off" or isn't in a frame). Adding new names for these specific failure categories doesn't seem useful to the platform. Additionally, many potential failure causes may have the same reason property[1] ("disabled" => SecurityError, WrongDocumentError?, InvalidAccessError?)** and the terminology differs slightly ("cancel" => AbortError). This seems confusing to web authors, so I propose a new type instead (in IDL): interface AutocompleteError : DOMException { readonly attribute DOMString reason; // matches AutocompleteErrorEvent's reason[1] }; This new type would have a code of 0 (as other new exceptions have; code is deprecated). I've filed a bug to add this to the DOMException name table[2]. -- Dan Beam db...@chomium.org [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#the-autocompleteerrorevent-interface [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457 ** names with "?" are the closest existing error names I could find (but aren’t great)
Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
From: db...@google.com [mailto:db...@google.com] On Behalf Of Dan Beam > So just pass no argument at all (i.e. arguments.length == 0)? I was under > the impression some type of value should always be returned (but I'm biased > by blink/v8's current implementation). It's equivalent, both for promises and for return values of functions. Both `new Promise(resolve => resolve())` and `new Promise(resolve => resolve(undefined))` give a promise whose fulfillment value is `undefined`. In this sense `resolve` behaves like all non-evil JavaScript functions, where evil is defined as "checking `arguments.length`" ;)
Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
On Mon, Apr 14, 2014 at 9:44 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > > From: whatwg-boun...@lists.whatwg.org [mailto: whatwg-boun...@lists.whatwg.org] On Behalf Of Dan Beam > > > I propose requestAutocomplete()[1] should return a Promise. This has been requested since the creation of this API[2][3] and seems like a natural fit. Web authors can then call requestAutocomplete() like this: > > I strongly support this. > > > Null would be passed on fulfillment* and > > `undefined` would be better, as that is what normal JavaScript functions return when they have nothing to return. So just pass no argument at all (i.e. arguments.length == 0)? I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). > > > {"reason": } would be passed on rejection. > > Rejection reasons should always be instanceof Error: https://github.com/w3ctag/promises-guide#rejection-reasons-should-be-errors > Great, will figure out a way to subclass Error to provide some type of "reason" property on the rejection argument. -- Dan Beam db...@chromium.org
Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dan Beam > I propose requestAutocomplete()[1] should return a Promise. This has been > requested since the creation of this API[2][3] and seems like a natural fit. > Web authors can then call requestAutocomplete() like this: I strongly support this. > Null would be passed on fulfillment* and `undefined` would be better, as that is what normal JavaScript functions return when they have nothing to return. > {"reason": } would be passed on > rejection. Rejection reasons should always be instanceof Error: https://github.com/w3ctag/promises-guide#rejection-reasons-should-be-errors