Bug 282849 – HTMLElement.requestPointerLock does not return a Promise

• Status: RESOLVED
• Resolution: FIXED
• Component: UI Events

[Andrew Hodel]

HTMLElement.requestPointerLock is specified as returning a Promise at https://developer.mozilla.org/en-US/docs/Web/API/Element/requestPointerLock

[Karl Dubost]

Andrew,
what are you testing on?
what is the code you are using to test?

[Andrew Hodel]

Karl Dubost

I have confirmed this in Safari with `console.log(HTMLElement.requestPointerLock);`

[Abrar Rahman Protyasha]

While MDN has documented the Promise return type for a while, the spec change to materialize this return type has only changed relatively recently: https://github.com/w3c/pointerlock/commit/0e99fcf3daa23269bf2b019f5269a154088d2347

We currently do return a Promise type if the "Pointer Lock Options" web preference is enabled: https://github.com/WebKit/WebKit/blob/45ccb551a4e879774bdfbd0204476fcd1ff0ea48/Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml#L5700-L5713

Andrew, you can use this feature flag as a workaround.

In the meantime, we should consider making the feature flag stable.

[Andrew Hodel]

@comment #3

Abrar Rahman Protyasha

That is incorrect as you linked to a document that explains the concept of a pointer lock, not a document that documents the HTMLElement.requestPointerLock function.

No change in either of the documents you linked include changes of the HTMLElement.requestPointerLock function returning a Promise instead of the Object that it returns now.

You may be confused in that it returns an Object that has a Promise inside of it, but in proper English nomenclature of a programming language function, it does not return anything other than an Object.  The reason for this is because you could otherwise validate saying that any function returns an Error causing invalidation of all existing documentation of functions that return Object with Error as the value of a named field property inside the Object.

I'm sorry that you are involved in a story relating this to a feature flag.  That is unrelated to this work.

[Andrew Hodel]

@comment #3

There is no argument that HTMLElement.requestPointerLock must return a Promise.

In Safari it does not.

The confusion in your writing is of https://github.com/mdn/content/issues/36766 and it is completely unrelated to any feature flag and completely unrelated to this issue.

Again, HTMLElement.requestPointerLock must return a Promise.

[Andrew Hodel]

@comment #3

Abrar Rahman Protyasha

There is no possibility of making the feature flag stable.

The only possibility not requiring a feature flag for the function to work as the specification indicates.

Again, HTMLElement.requestPointerLock must return a Promise.

[Andrew Hodel]

@comment #3

Abrar Rahman Protyasha

It is not acceptable to require that a feature flag be enabled in the browser settings for a standardized specification to work as specified because it would mean that all users of any website using that specification are required to enable the feature flag.  That is unacceptable.

Again, HTMLElement.requestPointerLock must return a Promise to be valid per the specification it is implemented of.

[Tim Nguyen (:ntim)]

To be clear, we agree with you, this bug report is accurate, and we need to make this change.

The reason why returning a Promise is currently behind a feature flag is that the specification hasn't been yet finalized when our code was written. At this time, the feature flag is not needed any more. Can you confirm that enabling the feature provides what you need?

If it does, we'll go ahead and looking into removing that feature flag, to make the change available to everyone.

[Karl Dubost]

const element = document.createElement('div'); 
console.log('requestPointerLock: ', element.requestpointerLock());

Safari:  undefined
Firefox: undefined 
Chrome:  Promise

Tested in 

Safari Technology Preview  206           20621.1.3.21.1
Firefox Nightly            134.0a1       13424.11.7
Google Chrome Canary       133.0.6835.0  6835.0

[Abrar Rahman Protyasha]

And, to add to Karl's latest findings, with the "Pointer Lock Options" feature flag enabled, this is what I see with ToT MiniBrowser:

```
requestPointerLock:  Promise {}
```

[Radar WebKit Bug Importer]

<rdar://problem/139854530>

[Abrar Rahman Protyasha]

Pull request: https://github.com/WebKit/WebKit/pull/36631

[EWS]

Committed 286597@main (2f0bfa7da8bb): <https://commits.webkit.org/286597@main>

Reviewed commits have been landed. Closing PR #36631 and removing active labels.