RE: gUM constraints webidl implementer feedback

This approach is not very forward-compatible. What if in the future "unknownKey" gets added to the spec. It is now not possible for a web developer to use that new key in a mandatory constraint because only the latest version of an implementation that supports that new key would allow it, other older UAs would throw the error/exception-this would lead to browser-detection practices which are just not good. By forcing any unknown key to throw an error you are effectively cutting off the ability to extend mandatory constraints in the future. Dictionaries are designed around this principle.

A basic principle of web API design is to be forward-compatible. This is why tag names that aren't defined by HTML are still allowed, why JavaScript APIs can accept extra parameters and do not throw, why CSS rules can take a variety of unknown properties and it doesn't invalidate the rule, etc.

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Friday, October 18, 2013 9:33 PM
To: Jan-Ivar Bruaroey; Travis Leithead; public-media-capture@w3.org
Subject: Re: gUM constraints webidl implementer feedback

On 10/19/2013 01:38 AM, Jan-Ivar Bruaroey wrote:
So we can't add more mandatory constraints over time?

Define "not to support any random property". Fail or silently succeed?

The behaviour I want is:

getUserMedia(.... mandatory(knownKey='foo', unknownKey='bar') ...)

should call the error callback ("constraints can't be satisfied"), with "unknownKey='bar'" as the constraint that couldn't be satisfied.

getUserMedia(.... optional((knownKey='foo'), (unknownKey='bar')) ...)

should silently succeed.

If that means dictionaries aren't the right object, we'll have to use something else.




.: Jan-Ivar :.

On 10/17/13 4:22 PM, Travis Leithead wrote:
WebIDL dictionary processing only knows how to deal with known dictionary members (see http://dev.w3.org/2006/webapi/WebIDL/#es-dictionary). Dictionaries are not generic property maps or sets.

In getUserMedia, the intention is to have a set of well-defined mandatory constraints (as defined by dictionaries in the spec--or inherited/partial dictionaries defined formerly elsewhere)-not to support any random property key that is placed on the dictionary object by user code.

From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
Sent: Wednesday, October 16, 2013 12:40 PM
To: Harald Alvestrand; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: Re: gUM constraints webidl implementer feedback

On 10/16/13 6:42 AM, Harald Alvestrand wrote:
On 10/15/2013 08:28 PM, Jan-Ivar Bruaroey wrote:

  1.  Mandatory constraints aren't implementable as webidl dictionaries.

     *   We're supposed to detect unknown mandatory constraints and fail on them, but webidl dictionaries silently ignore unknown keys!

I thought this was a feature... don't you get to see the ignored keys in the engine?

No, our webidl-compiler-generated bindings create a new dictionary from default values and then interrogates known members it finds in the provided content JS object through inspection. This is for security reasons, as content JS objects may be toxic. - Unknown members have unknown types, so including them safely becomes tricky.



1.

     *   To work around this problem, I had to alter the API to take the mandatory member as a plain object (which makes our webidl security guys' neck-hair stand up, but it's ok), like this:

        *   dictionary MediaTrackConstraints {
    object mandatory; // so we can see unknown + unsupported constraints
    sequence<MediaTrackConstraint> _optional;
};

     *   I then convert it internally to this structure after scanning for unknown keys, which should be safe:

        *   dictionary MediaTrackConstraintsInternal {
    MediaTrackConstraintSet mandatory; // holds only supported constraints
    sequence<MediaTrackConstraint> _optional;
};

In lieu of alternative solutions to number 6, I'd like to see the spec be explicit about what's needed to implement this as it stands.

Seems to me we have a differing understanding of how the engine should deal with dictionaries.

I agree. Maybe the webidl group can help clarify?
.: Jan-Ivar :.

--
.: Jan-Ivar :.