PointerLockControls broken in update of chrome?

[randombitsofcode]

I noticed a new bug overnight in my FPS where the mouse movement doesn't track correctly; it is chrome specific and the PointerLock/FPS example is also affected:

https://threejs.org/examples/misc_controls_pointerlock.html

Just move the mouse around quickly for a bit and you'll notice it jumping erratically. If you log the movementX and movementY values, it spuriously throws in movements of 300 to 400 (or -300 to -400 pixels) every once in a while. (Edit: In other words, it appears that the API is adding approximately 360 degrees +/- to fast movement events, but not exactly 360 so it is resulting in large mouse jumps.)

Since this is only an issue in chrome (current version 62.0.3202.94), I'm a bit worried that it might not be an easy fix, but I haven't been able to implement any quick fixes aside from rejecting large numbers, which isn't really ideal.

My game uses the the dev branch of three.js, but the FPS example is obviously run on r88 and the bug still appears.

I don't follow chrome updates very closely, but I did a quick search and I couldn't find any specific update that might have broken their PointerLock API.

[Mugen87]

I'm unable to reproduce this in Chromium 62.0.3202.94 on Ubuntu. If this is actually a problem in the browser, you might want to file a bug at: https://bugs.chromium.org/p/chromium/issues/list

[haroldiedema]

I can confirm this is a chromium issue as I'm experiencing this with my game running in Electron as well.

The values outputted in event.mousemoveX and event.mousemoveY are jittering sometimes. However, in my case, it only seems to happen when you hold one of your mouse buttons down

Someone else already made a bug report for this it seems: https://bugs.chromium.org/p/chromium/issues/detail?id=781182

[randombitsofcode]

Wow! Looks like they've known about this bug for quite a while. I suppose this bug report can be closed then, unless there is still some issue with the (slightly, temporarily?) broken example.

FWIW, I am still in development and ignoring mousemoveX and Y values -100 < x < 100 makes the game playable, if annoying, so that will have to be my fix until chrome fixes the bug. Thanks for finding the bug report and attempting to recreate the error.

[haroldiedema]

I worked around it by lerping (very quickly) from the previous value to the current one. This ensures the one "frame" where the jittering occurs, is immediately cancelled out on the next frame.

So basically (in psuedo since I'm currently in the office and don't have my code with me):

// Keep track of mousemove delta:
let mouse_delta = {x: 0, y: 0};

document.addEventListener('mousemove', (event) => {
    mouse_delta.x = mouse_delta.x.lerp(event.mousemoveX, 100);
    mouse_delta.y = mouse_delta.y.lerp(event.mousemoveY, 100);
});

note: lerp(val, amount) is a standard lerping function I've put onto Number.prototype.

This solution isn't perfect, but it helps quite a lot compared to not having this. You might need to fiddle a bit with the lerp value amount (the 100 in the example).

Use mouse_delta.x and mouse_delta.y in your camera code instead of the raw input.

[Mugen87]

Closing since it's a browser issue. @haroldiedema Thanks for providing the link to the bug report 👍

https://bugs.chromium.org/p/chromium/issues/detail?id=781182