[whatwg] Media Stream API: What is the intended behaviour for undefined mandatory arguments?

[Cameron McCormack]

Tommy Widenflycht (ᛏᚮᛘᛘᚤ):
> Could we have some clarification for the below cases, please:
> 
> var u;
> var n = null;
> 
> // Should throw since u is undefined or just abort?
> navigator.webkitGetUserMedia("audio", u);

I don’t think Ian has made changes to the spec yet regarding interface
types not including null unless explicit made nullable.  So let me
assume for now that the spec says

  void getUserMedia
    (in DOMString options,
     in NavigatorUserMediaSuccessCallback? successCallback,
     in optional NavigatorUserMediaErrorCallback? errorCallback);

which I think is supported by the prose describing the method.  null
therefore is a value that can be passed to the two callback methods.

Per Web IDL at the moment, when there is no overloading, the types of
values passed to a method do not determine whether the call is to that
one unoverloaded method or not; it is assumed that you are calling that
method.  Therefore, each argument will just get converted according to
the rules in http://dev.w3.org/2006/webapi/WebIDL/#es-types.  This is a
nullable type, so we look at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/WebIDL/Overview.html?rev=1.292;content-type=text%2Fhtml#es-nullable-type
(as the spec looked earlier today).  Here, any value other than null is
converted according to the inner type.

There is a bug here: those rules should also explicitly consider
undefined as a JS value that is converted to an IDL null value.
Otherwise you would end up with a TypeError being thrown here, and I
don’t think that’s what you want.  It’s also inconsistent with what the
spec used to say before I made the recent change where null was removed
from interface types.

I’ve just fixed this bug now:
http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type

So if you pass undefined for successCallback it will be treated as null.

> // Will not throw but will abort.
> navigator.webkitGetUserMedia("audio", n);

Right.

> // Should throw because we are expecting at least two arguments.
> navigator.webkitGetUserMedia("audio");

Actually this should behave as if you called getUserMedia("audio",
undefined).  This is because of the different behaviour for overloading
I mentioned above; when there is overloading, you will get a TypeError
thrown if the number of actual arguments doesn’t match the expected
number of formal arguments for one of the overloads.

This difference in behaviour is sucky, and I’ll be looking at improving
this in Web IDL soon.

-- 
Cameron McCormack ≝ http://mcc.id.au/