movedX and movedY no longer update after calling requestPointerLock

[Mees0x4E]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• p5.strands
• WebGL
• DevOps, Build process, Unit testing
• Internationalization (i18n)
• Friendly Errors
• Other (specify if possible)

p5.js version

1.11.7

Web browser and version

No response

Operating system

No response

Steps to reproduce this

Steps (see snippet):

1. Write a program that calls requestPointerLock() on mouseClicked
2. Use movedX and movedY values, for example by displaying them on screen

Expectation:
When I move the mouse, it shows by how much the mouse moved that frame. After I click the mouse which calls requestPointerLock, the movedX and movedY will continue showing by how much the mouse moved, even if the mouse is now invisible and locked, as per the documentation on https://p5js.org/reference/p5/movedX/:

Note: movedX continues updating even when requestPointerLock() is active.

Reality:
When using p5 version 1.11.7 or onwards, after calling requestPointerLock, movedX and movedY now no longer update and stay at 0 even when moving my mouse around.
On p5 version 1.11.6 or below, it behaves as expected.

Although I haven't tested it, I suspect that Commit fbffbc1: Consistent movedX and movedY behaviour across zoom levels is the culprit.

Snippet:

function setup() {
  createCanvas(400, 400);
}

function draw() {
  background(220);
  text(movedX, 20, 20);
  text(movedY, 20, 40);
}
function mouseClicked() {
  requestPointerLock();
}

[ksen0]

Thanks for reporting this!

Below are some notes from looking into it; I made also a draft PR here that is used in this sketch where I was trying to bugfix the problematic mouse behaviro(s)

First, I've confirmed that reverting the changes in the commit mentioned above does fix the current bug.

That commit was initially addressing mouseX/Y inconsistent zoom behavior. @IIITM-Jay I can't reproduce the zoom bug in the draft build, can you? If you have a moment, could you check that sketch and see if the zoom problem still exists there, and on which Chrome version?

While working on the above, I also found another neighboring regression (observable when accessibility outputs are on). Starting at 1.11.4 .loc, when moving mouse beyond the screen:TypeError: Cannot read properties of null (reading 'locY') at undefined:53353:41 - while the above sketch isn't broken, it's a significant problem with behavior of mouse moving offscreen. This was introduced in src/accessibility/outputs.js in the fix for #7259. I included a fix for this one in the draft above because without such a fix, it's hard to have a manual test sketch.

I'll take a look again tomorrow, but if anyone has any additional/alternative ideas, please let me know.

[suryapratap64]

I want to solve this issue please assign me this work , As a beginners i trying to fix more bugs.

[Homaid]

hey @ksen0 I can confirm the revert restores pointer lock deltas, but it also drops the zoom-consistency improvement from fbffbc1. Could we try a scoped approach that keeps the zoom fix for normal mouse moves, and special cases the pointer-lock path?