Symptoms: the mouse drifts right on Firefox (only)
How to reproduce:
- export demo cart as an html page
- publish page on itch.io (or equivalent)
- run game on Firefox (MacOS or Windows - Linux is fine)
- notice mouse x-drifting
Note: does not occur when game is run locally
Note: does not occur when game is run fullscreen using the Pico8 button
Wild guess: suspect a Firefox bug regarding mouse coordinates and iframes?
Test cart:
- https://freds72.itch.io/mouse-lock-test
- password: mouse
Code:
function _init() poke(0x5f2d,0x5) end _x,_y=0,0 function _update() _x=mid(_x+stat(38),0,127) _y=mid(_y+stat(39),0,127) end function _draw() cls() print(_x.."/".._y,2,2,7) circfill(_x,_y,4,8) end |
I'm on Firefox 119.0 on Manjaro Linux and your cart on Itch doesn't exhibit any mouse drift for me. The circle moves when I move the mouse and doesn't when I don't. I am on a laptop using a trackpad (and the little red nub, it's a Thinkpad), so I don't know if that would make a difference.
Using Firefox 119.0 on all OSes, I've observed this issue on MacOS 11.7.9 and Windows 10.0.19045. Ubuntu 20.04 LTS with X11 does not experience it.
Unfortunately, it's not unique to web exports published on itch.io, it also occurs on Newgrounds, for example. On either, it only occurs in the embedded player in regular windowed mode. Fullscreen mode does not drift, and if you right-click and select "Open Frame in New Window", the non-embedded version also does not drift.
I'm not able to reproduce locally, as simply embedding into an iframe in another html file doesn't seem to cause drift. If you save the itch or newgrounds page from Firefox and open it locally (change the e.src path in the embedded script in the export's html file to wherever Firefox saved it to), the mouse also does not drift, which might be a clue? I noticed some of the JS reads from MouseEvent.clientX so I'm thinking it's something to do with Firefox's CSS box model and JS having trouble getting relative mouse coords from the viewport when embedded in an iframe, under whatever conditions are created by running embedded on itch/newgrounds servers. Looks like a bunch of height/width calculations are done in the <head> tag, so a CSS/JS race condition, maybe?
I also could only repro under an iframe (Win+FF+itch). It certainly does seem sensitive to layout: the bug happens only at particular window sizes and scales -- e.g. make the itch browser window a few pixels wider and the bug appears / disappears. So there might not be anything special about fullscreen.
Looking at SDL's emscripten implementation, I couldn't see anything there that could be producing errant SDL_MOUSEMOTION events.
This looks similar: https://bugzilla.mozilla.org/show_bug.cgi?id=1752138
Oh, hmm, I never thought about trying to resize the window, lol! 😅 I guess that rules out the race condition theory, bc I think if resizing forced a recalculation, the DOM would be hydrated at that point and everything would be good. Too bad that Bugzilla report never got followed up on. Also weird that Linux builds don't seem to be affected.
related with some hints + firefox fix revision range: https://github.com/i3/i3/issues/4302
[Please log in to post a comment]
