Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

requestPermission() and event handling clarification #74

Closed
rakuco opened this issue Apr 8, 2019 · 10 comments
Closed

requestPermission() and event handling clarification #74

rakuco opened this issue Apr 8, 2019 · 10 comments

Comments

@rakuco
Copy link
Member

rakuco commented Apr 8, 2019

@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
Copy link
Member

anssiko commented Apr 8, 2019

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
Copy link
Member

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
Copy link
Contributor

cdumez commented Apr 8, 2019

@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
Copy link
Member

anssiko commented Apr 8, 2019

@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
Copy link
Contributor

cdumez commented Apr 8, 2019

@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
Copy link
Member

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
Copy link
Member

anssiko commented Apr 9, 2019

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
Copy link

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
Copy link
Member

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
Copy link
Member Author

rakuco commented Feb 12, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants