According to the WebIDL specification (https://heycam.github.io/webidl/#idl-dictionaries):

"An ordered map with string keys can be implicitly treated as a dictionary value of a specific dictionary D if all of its entries correspond to dictionary members, in the correct order and with the correct types, and with appropriate entries for any required dictionary members."

To me the word "all" as used here implies that if there is an extra key present in the ordered map then it is not a valid instance of the dictionary D.

The Generic Sensors API is attempting to enable the detection of supported features by rejecting dictionary keys the user agent does not expect. If this is not supported by WebIDL dictionaries then we should define something with the necessary behavior for this particular specification.

My understanding is that "an ordered map with string keys" doesn't mean an ECMAScript value.  IDL Record value is an example of "ordered map (with string keys)".
https://heycam.github.io/webidl/#idl-record

An ECMAScript value is NOT IMPLICITLY treated as a IDL dictionary type value.  It's explicitly converted to an IDL dictionary type value.  The conversion steps are exactly defined at:
https://heycam.github.io/webidl/#es-dictionary
Following the steps, extra properties of the ECMAScript value is just ignored.

Plus, in this conversion algorithm, there is no need for the ECMAScript value to have an own property with a specific key name.  A value of a dictionary member is extracted via [[Get]].
https://tc39.github.io/ecma262/#sec-get-o-p
So, the following |proxy| can work as an IDL dictionary which only requires numeric dictionary members.

  let handler = {
    get: function(target, name) { return 42; }
  };
  let proxy = new Proxy({}, handler);

|proxy['any_key']| always returns 42.  So, all dictionary members' values will be 42 with this |proxy|.  Probably this is not what you imagine, but Web IDL and ECMAScript are defined in this way.

It seems to be a known issue in Web IDL https://github.com/heycam/webidl/issues/107 So far, we have no good ways to detect if any unexpected entries are present in the given ECMAScript object.
At the moment, feature detection works in the Generic Sensor API for existing options (the already specified ones). 

The planned new sensor options will be added only after https://github.com/heycam/webidl/issues/107 is fixed.

Is there a Generic Sensors spec issue we can mark as blocked on WebIDL issue?

@reillyg https://github.com/w3c/sensors/issues/361

 Issue 823636  has been merged into this issue.

The assigned owner "mikhail.pozdnyakov@intel.com" is not able to receive e-mails, please re-triage.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot