eirage@ please take a look.

 Issue 784122  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cbdf0d7f47fd42b199941383c45b7e09d374bc0c

commit cbdf0d7f47fd42b199941383c45b7e09d374bc0c
Author: Ella Ge <eirage@chromium.org>
Date: Thu Nov 16 00:52:24 2017

Send synthesize mouse move event if mouse is locked

crrev.com/c/612720 disabled send SynthesizeMouseEvent
when cursor is invisible.
However when pointer lock, we use MoveCursorTo() to move
cursor. Need a synthesize mouse move event to reset
positions.

Bug:  781182 
Change-Id: I6dabfff7472bd4454b1cb37dd805ea0368bae27f
Reviewed-on: https://chromium-review.googlesource.com/769931
Commit-Queue: Ella Ge <eirage@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516927}
[modify] https://crrev.com/cbdf0d7f47fd42b199941383c45b7e09d374bc0c/ui/aura/window_event_dispatcher.cc
[modify] https://crrev.com/cbdf0d7f47fd42b199941383c45b7e09d374bc0c/ui/aura/window_event_dispatcher_unittest.cc

eirage@ Your fix works for normal movements but dragging in pointer lock causes the bug to come back. It looks like SynthesizeMouseMoveEvent() is still skipping the synthetic event when Env::GetInstance()->mouse_button_flags() != 0.

aicommander@, yes you are right, the bug still happen when button down. Thanks for testing it. I'll take a look.

eirage@, do you have any news regarding this bug?

I'm asking because this specific issue also made it into the latest stable build of Electron, which I'm using to create a game which uses tracking camera controls (holding a mouse button down while dragging to pan the camera).

I would really like to see this issue get resolved before releasing the final product.

Thanks in advance!

I'm also eager to have this fixed since I have a project using first-person mouselook that I'd like to release soon. Thanks for working on it eirage@!

You can probably imagine that this makes my first person shooter unplayable. This definitely isn't a minor issue, there are tons of similar games out there. Needs to be fixed asap. Thank you.

Me too. Mouse movement is not stable (jumps to random position etc.). Please fix it. My game is unplayable :(. 

Chrome version: 62.0.3202.75  Channel: stable

Can confirm I have the same problem.

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

I can also confirm that this is still a serious issue. In fact, this bug is quite old - someone filed https://bugs.chromium.org/p/chromium/issues/detail?id=501963 in 2015.

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

We contacted Microsoft regarding this and it appears there is a bug in the Fall Creators update that causes the OS not to generate a WM_MOUSEMOVE after a SetCursor call. They indicated that it will be fixed for the next major release.

However I think we likely need to work around this issue because waiting until the spring release is likely not an option.

 Issue 793270  has been merged into this issue.

The random jumps don't appear in Firefox and Edge. I'm not convinced that this is a Windows bug. Moreover, I've seen this issue with Chrome years ago when I was on Windows 8.1.

OS: Windows 10 Version 1709 Build 16299.98 (x64)
Test suite: https://scheib.github.io/HTMLMisc/PointerLockLog.html
Firefox/57.0.2 (64-bit) (works as expected)
Microsoft Edge/41.16299.15.0 (64-bit) (choppy, but works as expected)
Chrome/63.0.3239.84 (64-bit) (random spikes +-350)

Thank you for looking into this!

Chrome is relying on specific behavior that has existed in the Win32 API that existed for a while and was recently broken in 16299. Microsoft confirmed this and that is why this is a recent spike.

We have a work around that should help in the interim. Your issues with Windows 8.1 must be related to something else.

Last time i saw this  bug 3 -4 months ago (Windows 10). I hope somebody will fix it. All games that use the PointerLock are broken :(.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ef655137bba0566caff4d4c26c45ee055e2c081d

commit ef655137bba0566caff4d4c26c45ee055e2c081d
Author: Ella Ge <eirage@chromium.org>
Date: Tue Dec 12 16:38:54 2017

set global_mouse_position after move cursor for windows

This CL is a workaround for fixing the pointer lock issue
caused by a bug in Windows Fall Creators update (16299).
Windows OS doesn't generate a WM_MOUSEMOVE after a SetCursor
call.
The code added here should be removed once Microsoft fix
the bug in their next release.

Bug:  781182 
Change-Id: I690d5017e079ab32ef3cb55a2b136e8d0140bc6b
Reviewed-on: https://chromium-review.googlesource.com/791330
Commit-Queue: Ella Ge <eirage@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523448}
[modify] https://crrev.com/ef655137bba0566caff4d4c26c45ee055e2c081d/content/browser/renderer_host/render_widget_host_view_event_handler.cc
[modify] https://crrev.com/ef655137bba0566caff4d4c26c45ee055e2c081d/content/browser/renderer_host/render_widget_host_view_event_handler.h

eirage@ Fix verified on 16299.125. Working properly for button down and button up cases now.

Any chance we could get these 2 commits backported to stable? The number of affected machines will only get larger as Microsoft continues their rollout of Fall Creators update. 3 more months of this will be pretty painful if we have to wait for Chrome 65 to hit stable.

I downloaded chromium 65.0.3293.0, working good for now.

Your change meets the bar and is auto-approved for M64. Please go ahead and merge the CL to branch 3282 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bfcbcab03882fa2b01d2351a41c0d93da070d97

commit 0bfcbcab03882fa2b01d2351a41c0d93da070d97
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Thu Dec 14 16:45:15 2017

set global_mouse_position after move cursor for windows

This CL is a workaround for fixing the pointer lock issue
caused by a bug in Windows Fall Creators update (16299).
Windows OS doesn't generate a WM_MOUSEMOVE after a SetCursor
call.
The code added here should be removed once Microsoft fix
the bug in their next release.

TBR=eirage@chromium.org

(cherry picked from commit ef655137bba0566caff4d4c26c45ee055e2c081d)

Bug:  781182 
Change-Id: I690d5017e079ab32ef3cb55a2b136e8d0140bc6b
Reviewed-on: https://chromium-review.googlesource.com/791330
Commit-Queue: Ella Ge <eirage@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#523448}
Reviewed-on: https://chromium-review.googlesource.com/826430
Cr-Commit-Position: refs/branch-heads/3282@{#229}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/0bfcbcab03882fa2b01d2351a41c0d93da070d97/content/browser/renderer_host/render_widget_host_view_event_handler.cc
[modify] https://crrev.com/0bfcbcab03882fa2b01d2351a41c0d93da070d97/content/browser/renderer_host/render_widget_host_view_event_handler.h

Tying together a few other threads:

This bug has also been seen in SDL:

https://bugzilla.libsdl.org/show_bug.cgi?id=3931

and is discussed here:
https://twitter.com/Doomed_Daniel/status/942911252858368001

If we want to request an earlier fix to Windows I can help with that. But, it may be too late for that to be worthwhile.

 Issue 796141  has been merged into this issue.

Confirmed with eirage@ offline and this issue has been fixed on Latest Beta#64.0.3282.39.

Still seeing this issue in dev build (65.0.3298.3) and Canary (65.0.3309.0)

Seeing this issue in:
Version 63.0.3239.132 (Official Build) (64-bit)

Changing the window size increases the frequency of the bad events coming in.. almost as if its when the "locked" cursor hits the edge of the browser window.

This was first reported by a co-worker.. and I was unable to reproduce it, then this morning, I loaded our app and it was happening right away. I opened multiple instances of our app, and saw the same behavior.

the demo here: http://media.tojicode.com/q3bsp/  showed the same behavior...

as well as this demo: https://threejs.org/examples/misc_controls_pointerlock.html

I've tried disabling all my extensions.

Killing+restarting browser doesn't "fix" it.

Please fix! Using a project called Janusvr which the cursor Jumps and Jitters because of this

 Issue 799710  has been merged into this issue.

#30: I can't reproduce on beta channel(64.0.3282.71) and canary(65.0.3317.2). If you can still reproduce it, could you describe how you reproduce it and attach a screen shot? it might be a separate bug


#31, #32: This fixed is in M64, you will need to wait for M64 stable release or switch to beta channel.

 Issue 801620  has been merged into this issue.

Hi all in the Chrome team, just wanted to send a word of thanks for fixing this annoying bug.  Even though it wasn't your doing, you managed to correct the Windows Fall Creator Update problem - I just tried it on Chrome 64 and everything is working again.

Thanks again!

While I can confirm on my Windows machines that upgrading Chrome from 63 to 64 fixed this issue, it still persists on Chrome OS. I'm not sure if this is to be expected or not as this bug was only filed against Windows but I felt I should mention it. I know this was always pegged as an issue due to a Windows bug but I have had this problem on Chrome OS since early last year (and possibly longer). I'm currently running 64.0.3282.122 (Official Build) beta (64-bit) on my Chromebook Pixel and both demo links above still exhibit the issue described here.

#37 - you should search for an existing issue for the Chrome OS variant and file a new one if you cannot find it, as this is, indeed, very Windows specific.

I also confirmed that 64.0.3282.119 has fixed this bug.
Thanks Chrome team!

 Issue 805630  has been merged into this issue.