On Wed, Sep 21, 2011 at 10:44 AM, Alexey Proskuryakov <a...@webkit.org> wrote: > > 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.
Is that a Mac thing? Mousing around in a fullscreen flash app on Linux or Windows 7 certainly doesn't pop up a menu bar when I hit the top. And the way out is always to hit ESC [although there's often a button as well, depending on the application], so I'm not sure what the problem with fullscreen mouse lock would be. > 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 > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
