Re: [XHR2] undefined as user/password arguments

On 4/11/12 12:26 PM, Boris Zbarsky wrote:
> On 4/11/12 6:57 AM, Jonas Sicking wrote:
>> open(DOMString method, DOMString url, optional boolean async, optional
>> DOMString? user, optional DOMString? password);
>>
>> This means that if anything other than null is passed as value for the
>> user/password arguments, then the value should be stringified per
>> normal WebIDL/ECMAScript rules. This includes if the value undefined
>> is passed
>
> That's not correct. For nullable types, ES undefined is converted to IDL
> null per step 3 of
> <http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type>. There's some
> extra complexity there around DOMString in step 1, but it only applies
> when [TreatUndefinedAs] is used, which it's not in this case.

Though the current prose talks about "if the arguent was not omitted", 
so treats null and undefined the same: as the argument being specified. 
  That seems buggy for the exact reasons Jonas lists.

What would make sense here is to either use [TreatUndefinedAs=Missing] 
(and condition the "no user or password" behavior off the IDL value 
being unspecified) or to give these things a default null value and 
condition the "no user or password" behavior off the IDL value being null.

The question that should decide us between those two options is whether 
passing null should be treated like something is set or not here.

-Boris

Received on Wednesday, 11 April 2012 16:43:50 UTC