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

Open
rakuco opened this issue Apr 8, 2019 · 7 comments

Comments

@rakuco
Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2019

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2019

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

This comment has been minimized.

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.