Edgar Chen
d98f16e74d
This is gated behind a new pref: dom.pointer-lock.reset-to-center-from-parent.enabled. The patch preserves the original behavior as much as possible when the pref is off. There are some changes that affect both code paths, but they are minor and should not affect the main logic. Here are some major change when the pref is enabled: - Pointer recentering and computation of the center point are now handled in the parent process. - Locking native pointer is initiated from parent process as well. - When a remote target requests pointer lock, the parent process captures the mouse on the top-level browser element. This is necessary because the center of the chrome window may not correspond to the web page (for example, when a DevTools panel is open and resized to be very large). - This patch introduces an optimization that recenters the pointer only when it moves within a 25% boundary buffer near the edge of the window, reducing the number of recentering operations. Since each platform now uses a native API to "lock" the pointer, we do not need to worry as much about the pointer escaping pointer lock by moving outside the browser window at high speed. Differential Revision: https://phabricator.services.mozilla.com/D296321
11 lines
418 B
INI
11 lines
418 B
INI
# See https://bugzilla.mozilla.org/show_bug.cgi?id=1255338#c32.
|
|
prefs: [dom.pointer-lock.reset-to-center-from-parent.enabled:true]
|
|
[pointerlock-maintains-mousedown.html?unadjustedmovement=true]
|
|
expected:
|
|
if os == "linux": ERROR
|
|
if os == "android": ERROR
|
|
[Tests that mousemove events during pointer lock report correct button state]
|
|
expected:
|
|
if os == "linux": FAIL
|
|
if os == "android": FAIL
|