282849 2024-11-08 11:57:37 -0800 HTMLElement.requestPointerLock does not return a Promise 2024-11-14 10:19:08 -0800 1 1 1 Unclassified WebKit UI Events Safari 18 Mac (Apple Silicon) macOS 15 RESOLVED FIXED InRadar P2 Normal --- 1 andrewhodel a_protyasha a_protyasha brandonstewart cdumez karlcow ntim webkit-bug-importer oldest_to_newest 2073908 0 andrewhodel 2024-11-08 11:57:37 -0800 HTMLElement.requestPointerLock is specified as returning a Promise at https://developer.mozilla.org/en-US/docs/Web/API/Element/requestPointerLock 2074743 1 karlcow 2024-11-12 23:11:36 -0800 Andrew, what are you testing on? what is the code you are using to test? 2074782 2 andrewhodel 2024-11-13 05:19:17 -0800 Karl Dubost I have confirmed this in Safari with `console.log(HTMLElement.requestPointerLock);` 2074874 3 a_protyasha 2024-11-13 11:05:16 -0800 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. 2074876 4 andrewhodel 2024-11-13 11:43:41 -0800 @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. 2074881 5 andrewhodel 2024-11-13 11:50:30 -0800 @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. 2074882 6 andrewhodel 2024-11-13 11:53:33 -0800 @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. 2074885 7 andrewhodel 2024-11-13 11:57:12 -0800 @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. 2074975 8 ntim 2024-11-13 16:35:23 -0800 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. 2074986 9 karlcow 2024-11-13 17:12:52 -0800 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 2074989 10 a_protyasha 2024-11-13 17:18:39 -0800 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 {} ``` 2075012 11 webkit-bug-importer 2024-11-13 22:37:31 -0800 <rdar://problem/139854530> 2075013 12 a_protyasha 2024-11-13 22:43:56 -0800 Pull request: https://github.com/WebKit/WebKit/pull/36631 2075112 13 ews-feeder 2024-11-14 10:19:06 -0800 Committed 286597@main (2f0bfa7da8bb): <https://commits.webkit.org/286597@main> Reviewed commits have been landed. Closing PR #36631 and removing active labels.