This API seems clearly necessary to implement traditional FPS game controls.
On the other hand, I would not want my browser to have this kind of functionality. Arguably the main benefit of browsers is that they cannot do many things, and are thus relatively safe to use, not yet triggering the sort of fear normally associated with installing software on desktop platforms. Interfering with mouse movement would be one of the most dangerous and frustrating things Web pages could possibly do. The specification draft acknowledges the problem of inability to interact with user agent and the rest of the OS in mouse lock mode. However, the suggested mitigations seem fairly weak. Users are not trained to hit Esc anytime their computer stops properly reacting to their actions - I certainly wouldn't think of doing that. A permanent reminder would be extremely annoying, and we cannot expect that it would be read anyway. Fullscreen is one mode where browsers are expected to take more control over user interaction. Perhaps mouse lock could be appropriate in fullscreen. However, regular fullscreen applications do not use a mouse lock, so users are not trained to escape it - one can always move the mouse pointer to top of screen to get back their menu bar. The only related case I can think of is emulators, which release the mouse on certain modifier keys, such as Cmd or Ctrl+Option. So, I'm not sure how a safe UI would work even in this case. I'm curious about the following provision in the spec: > Mouse events normally considered user gestures (e.g. mousedown, click) for > security purposes (such as when allowing pop-up windows) should not be > treated as user gestures when under mouse lock to prevent malicious cross > origin click redirecting. My understanding is that when browser is in control, the primary security concern is with making the user believe that they are interacting with a different site, and thus stealing confidential data the user types (especially passwords). Displaying a pop-up window sounds like a very minor issue when malicious code is already in main frame, can draw anything, and can control mouse movement. Is there a specific attack scenario where this limitation helps? - WBR, Alexey Proskuryakov 20.09.2011, в 20:53, Vincent Scheib написал(а): > I have proposed Mouse Lock to be adopted by the W3 WebEvents Working Group: > http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0064.html > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1424.html > > On Mon, Sep 12, 2011 at 4:50 PM, Vincent Scheib <sch...@chromium.org> wrote: > A Mouse Lock API has been under discussion on the W3 public-webapps list > "Mouse Lock"(1) and earlier "Mouse Capture for Canvas"(2). > > The primary goal is to enable use cases such as first person perspective 3D > applications. This is done by providing scripted access to mouse movement > data while locking the target of mouse events to a single element and > removing the cursor from view. > > I have been working to formalize the discussions into a draft specification: > http://goo.gl/9G8pd, and have a work in progress prototype for WebKit | > Chrome. I will publish a WIP patch when it is ready for more eyes. It will be > developed behind a compile (and runtime) time flag. > > I'd like to invite any specification discussion to the Mouse Lock thread (1), > and WebKit implementation discussion here. > > Cheers, -Vince > > -- > 1. > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960 > 2. > http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 > > W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 > Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602 > Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754 > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
