What specifically doesn't work? Do they not render (WebGL issue) or does your pointer not get locked (Pointer Lock issue)? Try googling "firefox pointer lock doesn't work", I'm sure something relevant will come up.
Same here, but chrome works.
I'm not sure it's a point lock issues, since that's supposed to work on FF.
In console, the difference I noticed is that FF has this error:
Firefox can't establish a connection to the server at ws://./. - shoote...tBqO.js (line 57)
Hmm. Enabling this for any element regardless of full-screen state might be a bad idea. Is the warning popup modal? Can you use it to cause the user to click on something other than the intended target by intentionally drawing the pointer in the wrong place?
Like JavaScript, this needs a default-disable, on for trusted sites only mode.
Well, chromium pops up a bar on the top with buttons for denying or accepting the request of the website to disable the cursor before it does anything.
I don't see why this is really a security issue. You can't control their pointer, it just becomes disabled. The popup and the pointer lock are managed by the browser, so you can't trick them into doing anything and they can always get out of it by just pressing escape.
Read the article - they specifically talk about drawing your own pointer. You don't need to control the pointer, you just need to make it appear to be somewhere else.
Remember all the shitty spam adverts themed to look like Windows XP dialog boxes? I can't wait to see what the bottom-feeders can come up with given this sort of feature.
At least it sounds like Chromium uses a modal yes/no question bar.
The mouse sends high DPI information to the OS, and the OS sends the applications the mouse info they request.
For drawing the pointer in the GUI, lots of DPIs correspond to moving just one pixel.
However, that's just too low resolution for gaming, where the full DPI information is preferable. Also, for gaming, mouse acceleration should be disabled.
The solution in other games is to read the original high DPI info, instead of the mouse screen coordinates.
Of course you are right about spam, but there's a technical reason for this implementation.
Was just looking at the Quake 3 demo and noticed the FPS was locked to 60. Wondering if this is a limitation of the demo or of the browser (FF nightly in my case).
If so that may turn out to be a bit short sighted in the long term.
15 comments
[ 1714 ms ] story [ 850 ms ] threadPointer Lock seems to work fine.
In console, the difference I noticed is that FF has this error: Firefox can't establish a connection to the server at ws://./. - shoote...tBqO.js (line 57)
Chrome doesn't have that error.
Like JavaScript, this needs a default-disable, on for trusted sites only mode.
Seems pretty solid to me.
Remember all the shitty spam adverts themed to look like Windows XP dialog boxes? I can't wait to see what the bottom-feeders can come up with given this sort of feature.
At least it sounds like Chromium uses a modal yes/no question bar.
The mouse sends high DPI information to the OS, and the OS sends the applications the mouse info they request.
For drawing the pointer in the GUI, lots of DPIs correspond to moving just one pixel.
However, that's just too low resolution for gaming, where the full DPI information is preferable. Also, for gaming, mouse acceleration should be disabled.
The solution in other games is to read the original high DPI info, instead of the mouse screen coordinates.
Of course you are right about spam, but there's a technical reason for this implementation.
Now when all browsers support it I will look more closely.
Thanks.
If so that may turn out to be a bit short sighted in the long term.