buggy on windows. tried playing with a mouse and keyboard on windows in edge… #307

No description.

Read the code for what it says about Windows and Edge rather than guessing, and there are four faults in the mouse-and-keyboard path that would each read as "buggy" from that platform and as nothing at all from a Mac. Split into four issues; this one now waits on them and stays open as the report they answer.

What the code says, on db506ac:

1. The pointer lock never asks for raw movement. src/client/main.ts:1026, :1036 and src/range/main.ts:208 call requestPointerLock() with no options, so event.movementX in src/engine/controls.ts:177 arrives with Windows' pointer speed and "enhance pointer precision" applied — non-linear, and a different angle for the same hand motion than on macOS. → #308
2. The lock's answer is discarded. void ...requestPointerLock() throws away a promise Chromium rejects when a lock is asked too soon after an exit or the document is not focused, and nothing listens for pointerlockerror. A click on Play can do nothing, silently. → #308
3. Your side buttons navigate the browser. The shooter's whole mouse table is { 0: "fire", 2: "scope" } (src/client/binding.ts:63), and nothing prevents mousedown/auxclick for buttons 3 and 4 — which are Back and Forward in Edge on Windows. A five-button mouse mid-round can leave the page. There is also no wheel binding at all, which is how a lot of people jump. → #309
4. Nobody can see what your machine did. ANGLE on D3D11 rejects shaders a desktop driver accepts, createRenderer throws with the driver's info log (src/engine/renderer.ts:164-175), and nothing catches that at boot — src/client/main.ts:1349 only checks that a WebGL2 context exists. A refused shader is a black canvas and no sentence. → #310, which also gives you one line to paste into a report like this one.
5. Windows display scaling. 125% and 150% are the common cases there and have never been looked at here: the crosshair's arms land on fractional device pixels. → #311

One thing already on the board becomes a Windows symptom: #74 — the world keeps stepping while the pause panel is up, and Alt+Tab is how a Windows player loses the lock. You can die reading the word Paused, and that will happen far more on Windows than anywhere else.

What would still help, if you have it: the line #310 adds is exactly what I would want — but before it exists, whether Play locked the mouse at all, whether the picture appeared or the canvas stayed black, and whether a side button or the wheel was involved would each point at a different one of the four.