This demo from MDN shows the problem.

https://mdn.github.io/dom-examples/pointer-lock/

Click into the box, move the mouse in small, slow circles. the movement down/right is significantly slower than the movement up/left, from the same input. 

Try this older Quake 3 webl demo with pointer lock:
http://media.tojicode.com/q3bsp/

  When you click inside the window, try rotating the camera 360 with your mouse - it has severe problems, it will hiccup, stutter and reset to previous starting position.  Please fix this soon, none of my webgl demos on my github page are working because of this issue.
Thank you

Further information: 
because this completely breaks my workflow, I've switched to the stable channel (Chrome 62), and this is functioning correctly. 

Also tested on Chrome 64 on Ubuntu 14.04, 16.04 and Window 10. in all cases the mouse movement reports correctly, so this looks like it might be a ChromeOS only issue.

Ella can you investigate this on Chrome OS?

I can confirm this issue is present in Version 63.0.3239.84 on Windows 10 (Fall creators update) 

The mouse is basically teleporting. This issue is only present in Chrome.

Deleted: 2018-01-03 02-02-02.mp4 15.9 MB

2018-01-03 02-02-02.mp4 15.9 MB Download

Yes, upon further investigation, ever since I installed the Fall Creator's update on Windows 10 (on my Toshiba Portege z935 laptop), the mouse capture has been malfunctioning in Chrome. Everything worked perfectly before this update.

Thanks for looking into this!

Are there any updates to this? 

#6, #7: This issue is about pointer lock movement speed inconsistent in ChromeOS. I believe the position jumping issue on Windows 10 you mentioned is a different issue. That issue is fixed in M64. (See  issue 781182 ) Thanks

@eirage, yes I was looking for the position jumping  issue 781182  - thank you for the clarification and the link!

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

commit 0b0b64bb42e0341bdf30cfe9896821d84bda942a
Author: Ella Ge <eirage@chromium.org>
Date: Tue Jan 16 16:40:19 2018

Use integer subtraction to calculate movement_x/y

This CL changes the calculation of movement_x/y from
"floor(cur_pos - last_pos)" to "floor(cur_pos) - floor(last_pos)"

We store mouse event coordinates as pointF,
If we have mouse move like: 0 -> 1.4 -> 2.8 -> 4.2
"floor(cur_pos - last_pos)" will get movement:
0->1.4=1; 1.4->2.8=1; 2.8->4.2=1. in total is 3.
So that'll lose fraction part movement.
To get correct movement_x/y, need to use
"floor(cur_pos) - floor(last_pos)" instead.

Bug:  795179 
Change-Id: Iabae78962541cacc9f6a79eb0290a610f1818f02
Reviewed-on: https://chromium-review.googlesource.com/862903
Commit-Queue: Ella Ge <eirage@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529440}
[modify] https://crrev.com/0b0b64bb42e0341bdf30cfe9896821d84bda942a/content/browser/renderer_host/render_widget_host_view_event_handler.cc
[modify] https://crrev.com/0b0b64bb42e0341bdf30cfe9896821d84bda942a/third_party/WebKit/LayoutTests/NeverFixTests
[modify] https://crrev.com/0b0b64bb42e0341bdf30cfe9896821d84bda942a/third_party/WebKit/LayoutTests/external/wpt/pointerlock/movementX_Y_basic-manual.html
[add] https://crrev.com/0b0b64bb42e0341bdf30cfe9896821d84bda942a/third_party/WebKit/LayoutTests/external/wpt_automation/pointerlock/movementX_Y_basic-manual-automation.js