Re: Mouse Capture for Canvas

On 2/8/2011 8:03 PM, Glenn Maynard wrote:
> On Tue, Feb 8, 2011 at 10:27 PM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>
>>     - It's a major break from the normal event model.  Merely
>>     defining an event shouldn't cause side-effects.
>     This proposal seems to say that mouse capture is enabled by adding
>     an event handler to an element.  I don't like this:
>     window.open is another item that only fires during an event
>     handle. I'm sure full screen is on that grounds.
>     Drag+drop does that.  [input type=file] is another.
>
>
> Sorry, that's not what I meant.  It's OK--if less than ideal--for 
> functionality to *only be available* during certain events.  What I 
> meant was that this proposal seems to cause mouse capture to happen as 
> a side-effect of the event handler being set at all.  Adding the 
> "mousecapture" event causes clicking the element to capture.  That's 
> what I don't like in particular.
>
I missed that ("mousecapture").

>
>     User initiated events are part of the security model; and the
>     current issues with mouse capture are about security.
>
>
> I typed this before but elided it since my mail got too long: 
> window.open is an example of why restricting these things to clicks 
> doesn't work very well.  Browsers tried to prevent unwanted popups by 
> only allowing them during clicks, and now instead of popups opening 
> when you load a page, they open the first time you click anywhere in 
> the window.
I've found it to be an improvement. If I don't click on a page, it's not 
going to spring nastiness on me.
Passive indicators provide some middle ground, though I find it to be a 
little difficult with [html manifest] in Firefox, but it's still an 
improvement.

> 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.

As I understand things, operating systems have their function keys: the 
Windows key, the Mac key, the single special button on the iPhone, and 
so on.
(I use Win all the time when things go wrong)

Otherwise, they haven't gotten any further on the issue. Well... there's 
also the reset key, the power button, and the plug that runs out of the 
computer,
or the switch that releases the battery.