1252749 - requestPointerLock should fire a pointerlockerror event if permission is denied

Status: RESOLVED WONTFIX

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Christopher Van Wiemeersch [:cvan]]

1. Load https://people.mozilla.org/~cwiemeersch/pointerlockerror-bug.html
2. Click the 'lock' button and deny the Pointer Lock request (from the door-hanger modal: 'Hide pointer' > 'Not Now')
3. Notice no events are fired indicating as such (neither `pointerlockerror` nor `pointerlockchange`)

FWIW, Chrome fires the `pointerlockerror` event (as of https://bugs.chromium.org/p/chromium/issues/detail?id=419493) if the user rejects the permission prompt.

Comment 1

[Andrew Overholt [:overholt]]

Marcos, this is the same as bug 1252657 and the underlying issue, right?

Comment 2

[Christopher Van Wiemeersch [:cvan]]

Marcos, ideally, Pointer Lock permissioning would be handled by the Permissions API but — according to https://w3c.github.io/permissions/#permission-registry — it doesn't look like that's (yet) one of the supported APIs. (The list does appear to be growing over time, so that's good!)

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Per spec pointerlockerror doesn't need to be fired.
The only case when the spec explicitly says the event should be fired is
"If any element in another document is already locked the request must fail and a pointerlockerror event be sent."

There is the sentence "The user agent determines if pointer lock state will be entered and upon lock state change or error must send either a pointerlockchange or pointerlockerror event respectively. "
but that doesn't actually define when to dispatch what, and if user doesn't say anything, no event will be dispatched.

cvan, want to file a spec bug?

Comment 4

[Marcos Caceres [:marcosc]]

(In reply to Andrew Overholt [:overholt] from comment #1)
> Marcos, this is the same as bug 1252657 and the underlying issue, right?

Yep. Looks like same problem. 

(In reply to Christopher Van Wiemeersch [:cvan] from comment #2)
> Marcos, ideally, Pointer Lock permissioning would be handled by the
> Permissions API but — according to
> https://w3c.github.io/permissions/#permission-registry — it doesn't look
> like that's (yet) one of the supported APIs. (The list does appear to be
> growing over time, so that's good!)

Filed bug: https://github.com/w3c/permissions/issues/67


(In reply to Olli Pettay [:smaug] from comment #3)
> Per spec pointerlockerror doesn't need to be fired.
> The only case when the spec explicitly says the event should be fired is
> "If any element in another document is already locked the request must fail
> and a pointerlockerror event be sent."
> 
> There is the sentence "The user agent determines if pointer lock state will
> be entered and upon lock state change or error must send either a
> pointerlockchange or pointerlockerror event respectively. "
> but that doesn't actually define when to dispatch what, and if user doesn't
> say anything, no event will be dispatched.
> 
> cvan, want to file a spec bug?

It should be a PermissionDenied error... IIRC, that's being added to WebIDL.

Comment 5

[Edgar Chen [:edgar]]

Per https://github.com/w3c/permissions/issues/67 and Firefox have removed the permission prompt for pointer lock, so close as WONFIX.