requestPermission() and event handling clarification

[rakuco]

@reillyeon and I were discussing the Chromium implementation of #68 and we figured it'd be good to get some clarification on how it integrates with Device{Orientation,Motion}Event -- either in terms of what the spec's supposed to mean or, if it's intentionally leaving some decisions up to implementations, what WebKit/Safari do so we can try to align some of the behavior across implementations.

• Does WebKit/Safari remember if permission's been granted to a given page or are users always asked for permission when requestPermission() is called?
• If an event listener for a deviceorientation/motion event is added before permission is granted, does anything happen (e.g. a null deviceorientation/motion event is fired)?
• Are users at all supposed to be able to add an event listener for those events before requesting permission?
• Once permission is granted, do previously registered event listeners start working or does the user need to add another event listener in order to start receiving events?

cc @cdumez

[anssiko]

As a related comment, my assessment is that this clarification should not block the publication of the Working Draft that is imminent. If you think otherwise, please shout out now. We can always publish a new WD with clarified content.

[reillyeon]

Persistence is something that can be left up to the implementation to decide but my sense is that developers will have to write different code depending on the answers to the last three questions.

[cdumez]

@reillyeon and I were discussing the Chromium implementation of #68 and we figured it'd be good to get some clarification on how it integrates with Device{Orientation,Motion}Event -- either in terms of what the spec's supposed to mean or, if it's intentionally leaving some decisions up to implementations, what WebKit/Safari do so we can try to align some of the behavior across implementations.

• Does WebKit/Safari remember if permission's been granted to a given page or are users always asked for permission when requestPermission() is called?

WebKit only remembers for the lifetime of the web page. Safari might remember for longer, it is unclear at this point.

• If an event listener for a deviceorientation/motion event is added before permission is granted, does anything happen (e.g. a null deviceorientation/motion event is fired)?

In WebKit, you can register an event listener right away but deviceorientation / devicemotion events will not be fired until permission is granted. We currently log a console message when registering an event listener before permission is granted to let developers know.

• Are users at all supposed to be able to add an event listener for those events before requesting permission?

As it is implemented in WebKit, yes. There is not really a precedent (AFAIK) for preventing somebody from adding an event listener. I think it is much nicer to developers as well to allow registering the event listener, but delay firing of events until permission is granted.

• Once permission is granted, do previously registered event listeners start working or does the user need to add another event listener in order to start receiving events?

Yes, existing event listeners start receiving events.

[anssiko]

@cdumez, thanks for the clarifications. I assume there’s a typo in:

No, deviceorientation / devicemotion events are fired until permission is granted.

And it should read ”events are not fired” to make sense in this context?

[cdumez]

@cdumez, thanks for the clarifications. I assume there’s a typo in:

No, deviceorientation / devicemotion events are fired until permission is granted.

And it should read ”events are not fired” to make sense in this context?

Yes, I fixed my reply. Thanks.

[reillyeon]

Thanks for the clarifications. This behavior seems good to me. My only concern was that waiting to fire events would cause pages to get stuck waiting for confirmation that sensors are or are not available. On the other hand firing an empty event would would raise the question of whether we should fire another one after the page calls requestPermission() on a device without sensors.

@rakuco, let's follow WebKit's lead and implement it this way in Blink and report back if we find any interesting corner cases. This behavior should also be specced eventually.

[anssiko]

My suggestion is we link to this issue from the spec (see #75) and publish a WD as planned. Then, after we've baked in the clarifications based on Blink's implementation experience, we publish another WD.

By doing this, I feel we might get further feedback from the broader community (outside this WG, including other browser vendors not in this group yet) who might review the new WD of the specification.

[stepancar]

The URL https://www.w3.org/TR/orientation-event/#gesture-recognition indicates that shake event tracking is a use case of this API. However, the requestPermission function only stores permission per session, making it impossible to implement an app that tracks shake events as defined in the use case. To enable the tracking of shake events, it is necessary to request permissions every time a new session starts.

[reillyeon]

The URL https://www.w3.org/TR/orientation-event/#gesture-recognition indicates that shake event tracking is a use case of this API. However, the requestPermission function only stores permission per session, making it impossible to implement an app that tracks shake events as defined in the use case. To enable the tracking of shake events, it is necessary to request permissions every time a new session starts.

Whether or for how long permissions persist between sessions is a user agent decision outside the scope of this specification.

[rakuco]

I think this has been addressed by #123 and the current spec text matches WebKit's behavior as described above.