How to check when permission is denied?

[anssiko]

TAG guides: Don’t expose unnecessary information about devices.

@reillyeon notes:

• when no permission is granted no event is fired
• when the sensors are unable to provide readings (either entirely or for a particular feature e.g. the gyroscope) an event with those readings set to null is fired.

Context: https://github.com/w3ctag/design-reviews/issues/928

A feature or a bug?

[rakuco]

I think this also concerns the Permissions Policy integration, even if tangentially.

Permissions Policy integration does not fall under the same "a web app should not be able to distinguish between the user rejecting permission to use a sensor/capability, and the sensor/capability not being present" TAG guideline, but most other specs throw a DOM exception like NotAllowedError when a Permissions Policy check fails, whereas this specification just avoids firing any events.

Both Blink and WebKit seem to do this at the moment, but WebKit had to add a workaround for at least one domain affected by this behavior: https://github.com/WebKit/WebKit/blob/09ad6a20c559b27ada2b2e8bf859dc90930fb23f/Source/WebCore/page/LocalDOMWindow.cpp#L2194

_(Gecko has not implemented Permissions Policy integration yet)_

[reillyeon]

It would be good to get more input from WebKit given their implementation experience. My gut feeling is that when a site doesn't have permission to use the API an empty event should be fired. CC @cdumez.

[marcoscaceres]

I don't think that (firing empty event) aligns with any other API with respect to permission policy... permissions checks should be done with the Permission API's .query().

[reillyeon]

I agree developers can and should use the Permission API to query permission state. The question is how to align the specified behavior of this API with this TAG guidance:

A web app should not be able to distinguish between the user rejecting permission to use a sensor/capability, and the sensor/capability not being present.

[marcoscaceres]

I think returning "denied" when the capability is not available from the Permission API would address the issue.

This is because, the use could theoretically previously deny the permission globally, even if the sensor is available. That would make it indistinguishable.

Calling .requestPermissions() and permissions.query() would both return "denied".

[reillyeon]

I agree returning "denied" from query() is part of a solution to this problem. For backwards compatibility I still think we should fire an empty event when permission is denied (either by the user or because there are no sensors). This would be consistent with the TAG guidence.

[marcoscaceres]

For backwards compatibility I still think we should fire an empty event when permission is denied (either by the user or because there are no sensors)

can you help me understand this a bit more? WebKit only does this as a quirk for a single website. The quirk was added a few years ago.

I’m still a little bit unsure what the purpose of firing the event would be over just returning “denied”.

Maybe the question is: how much breakage is there if we don’t fire the event?

[reillyeon]

I’m still a little bit unsure what the purpose of firing the event would be over just returning “denied”.

The purpose is purely compatibility. Sites already expect the empty event behavior because that's what happens on devices which don't support orientation, so the change is guaranteed to cause less breakage as browsers implement a permission requirement.

Maybe the question is: how much breakage is there if we don’t fire the event?

It caused enough breakage that WebKit added a quirk. I'm guessing smaller sites (e.g. mobile web games) are either broken or fixed it after noticing.