Re: Possible compat problem with treating undefined as not passed in WebIDL

On Wed, Oct 2, 2013 at 7:32 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Consider this script:
>
>   try {
>     var xhr = new XMLHttpRequest();
>     xhr.open("GET", "http://example.org", undefined);
>     xhr.send();
>     alert("Undefined treated as not passed");
>   } catch (e) {
>     alert("Undefined treated as false");
>   }
>
> Note that the WebIDL for XMLHttpRequest.prototype.open is:
>
>    void open(ByteString method, DOMString url,
>              optional boolean async = true,
>              optional DOMString? user,
>              optional DOMString? password);
>
> In current browsers the above testcase throws an exception, because the
> XHR ends up sync: the undefined is coerced to bool, and ends up false.
>
> But if undefined is treated as missing (as I just tried to do in Gecko),
> the XHR ends up _async_, and no exception is thrown.
>
> It's possible that in this case we can simply rewrite the IDL like so:
>
>    void open(ByteString method, DOMString url);
>    void open(ByteString method, DOMString url,
>              boolean async,
>              optional DOMString? user,
>              optional DOMString? password);
>
> with prose saying that the two-argument form is async.  That would
> preserve the current behavior, which I expect the web depends on....
>
>
FWIW, Blink has "custom" binding code for this one and switches behavior
based on the argument count anyway. (Blink's binding generator has not yet
been taught the full intricacies of overload resolution or defaults.)

Having an optional boolean argument default to "true" seems like poor JS
API design for this reason. Hopefully there isn't much of it in the
platform, and therefore overloads and/or prose is acceptable in legacy
cases. Are you aware of other examples?

The developer feedback on the APIs I've worked on is very strong that
passing undefined is expected to behave the same behavior as not passed,
and I'd rather decorate (etc) legacy methods, even if there are many of
them. (Web IDL already has [TreatUndefinedAs=XXX] for legacy DOMString
cases)

I tried a local experiment a while back with a hacky partial implementation
of undefined ~= not passed in Blink; it tripped up only a handful of test
failures that were exercising passing explicit undefined and expecting
coercions, but I think that says more about test coverage than Web
compatibility.