- From: Brandon Andrews <warcraftthreeft@sbcglobal.net>
- Date: Wed, 9 Feb 2011 16:20:59 -0800 (PST)
- To: Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>
- Cc: Kenneth Russell <kbr@google.com>, robert@ocallahan.org, public-webapps@w3.org
- Message-ID: <617410.6049.qm@web83809.mail.sp1.yahoo.com>
> On Tue, Feb 8, 2011 at 11:09 PM, Charles Pritchard <chuck@jumis.com> wrote: >> That said, it would still help prevent non-malicious but misbehaving >> scripts from accidentally taking over the browser, which can happen >> anywhere, even on "trusted" sites. However, that's just one possible way of >> dealing with that problem, and browsers should be able to look for less >> restrictive solutions (which is what I had in mind when I referred to how >> operating systems deal with this). >> >> "Trusted" sites aren't well defined, so for the time being, I'm fine with >> them taking over the browser. >> > In this case, I'm mostly referring to sites where you've previously clicked > "always allow this site to do this"--probably the usual case. Legitimate > sites aren't going to deliberately hijack the mouse cursor, but it might > happen due to a bug, and I must always be able to escape without having to > close the whole browser window. When I wrote this up I was thinking of the easiest way to handle this without allowing a webpage to take a mouse over and over. To make things more flexible it could be simply on mouse down instead of click. Mouse down would allow a person to click and continue moving the mouse inside of the region without releasing. Regarding forcing a user action before the mouse is captured/grabbed I think it's pivotal. If a page can simply call a method to capture the mouse everytime it's released it because exploitable. If a person accidently allows a page to capture their mouse they can just press the release key. > For an API, I'd suggest simply adding "element.captureMouse()" and > "element.releaseMouse()", with events when the mouse is actually captured > and released. Browsers can still choose to ignore captureMouse if not > called in response to a click, and the spec can require that at the start if > that's really wanted, but that behavior isn't baked permanently into the API > and could be relaxed later on. I hate to ask, since there could be use cases I'm missing, but what is a use case where a browser would need to grab the mouse immediately when the page starts? I'm not against the idea, but it might need a strategy to stop abuse. Here are some steps I see happening. 1) User directs their user-agent to a new page. 2) Javascript calls mousecapture 3) user-agent displays a yellow bar at the top informing the user that the page is requesting to capture the mouse 4) User selects allow 5) User presses escape 6) In the mouserelease callback there's a mousecapture call 7) User is confused why mouse didn't release and kills 6 people. So we have to stop that (the mouse release and immediate capture). My proposal is if the user presses the release key twice in a row the yellow allow/deny bar is reset. But that assumes every human reacts the same way to mouse that is locked and keeps hitting the escape key. You'll need to find a solution because I can't think of one that works. Also what are your guy's name ideas? I think I prefer mousecapture and mouserelease and just push aside the IE API.
Received on Thursday, 10 February 2011 00:21:32 UTC