Passing base dictionary wont work.

[jan-ivar]

Same thing as happened in getStats, a WebIDL method taking a base PermissionDescriptor dictionary wont see any members from derived dictionaries, e.g. deviceId from DevicePermissionDescriptor, so this API needs to take object, interfaces, or be rethought.

Also #42 may be related.

[jan-ivar]

In #42 (comment) @jyasskin wrote:

@jan-ivar Can you link to an explanation of the security claim?

Gecko implements some APIs in JavaScript. We have a DOM membrane (compartments), but WebIDL bindings provide another layer of security by formalizing access, so mistakes are not made interrogating inputs in ways which could cause unintended side-effects.

object and any pose a special risk in that they put more burden on the implementer of each API to handle cross-compartment objects manually and with care. Specifically: avoiding accidentally executing potentially malicious JavaScript objects from privileged code (e.g. an innocent-looking getter may cause side-effects or manage to invoke malicious code directly).

As the prose in this spec is currently written, we can't implement it in JavaScript, which would be unusual. We'd need new support methods specifically to interrogate objects and convert them to safe dictionaries (which is doable, just more work).

Security aside, I think there's also a prevailing view that WebIDL was designed around facilitating good API design only, and conversely that something requiring prose and not fitting in could be a symptom of bad API design. This is a hygiene argument, though it fits my personal disdain for lateral APIs (though I sympathize with .query being hard to define without it. However, that sympathy does not extend to .request and .revoke, which attempt to replace already-correct domain-APIs without WebIDL problems).

[jyasskin]

I think #125 handles the above security concerns by saying to convert the objects to particular IDL types before using them. An implementation can probably optimize away the first conversion by fetching .name directly, but it seemed cleaner for the spec to just call the conversion twice.

[jyasskin]

Another way to implement these functions is to treat their parameter types as a union of all descriptor types. I'm not doing it that way in the spec because I want to have to update as little as possible in this spec when another spec wants to define a new powerful feature.

[jan-ivar]

Tried that. Union members must be distinguishable, so there cannot be two dictionaries in a union.