Re: Mouse Capture for Canvas
Sorry I don't have anything to add to the main discussion points but I want to point out that this should NOT be limited to the canvas tag. There are whole game engines that work on nothing but manipulating DOM elements with z-index and setting style.left and style.top. I can imagine plenty of other apps that don't use canvas that might benefit from mouselock. A mapping page. A graph exploration page. A photo viewing page.
Re: Mouse Capture for Canvas
Sorry I don't have anything to add to the main discussion points but I want to point out that this should NOT be limited to the canvas tag. There are whole game engines that work on nothing but manipulating DOM elements with z-index and setting style.left and style.top. I can imagine plenty of other apps that don't use canvas that might benefit from mouselock. A mapping page. A graph exploration page. A photo viewing page. -- Gregg Tavares Sounds like a good idea then to allow it on any element. It's nice to see people are seeing other applications for it.
Re: Mouse Capture for Canvas
On Tue, Feb 8, 2011 at 11:09 PM, Charles Pritchard ch...@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.
Re: Mouse Capture for Canvas
(Hello, Brandon) On Wed, Feb 9, 2011 at 7:20 PM, Brandon Andrews warcraftthre...@sbcglobal.net wrote: 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. It's only exploitable if there are no other mechanisms to prevent abuse. Requiring a click isn't the only conceivable way of doing that. Also, trusted applications may want to relax restrictions like this, to allow web apps to behave more like native applications. Even if implementations will usually require a click, there's no need to bolt that into the API and make it impossible to change 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. If I load a first-person game in a tab, I shouldn't need to click the window to allow the page to capture the mouse. That'll force every game to start with a superfluous box saying click here to start. Also what are your guy's name ideas? I think I prefer mousecapture and mouserelease and just push aside the IE API. Mouse capture isn't just an IE API. There's also a similar Win32 API with the same name, with the same use case as IE's API: to continue receiving mouse motion when dragging. I'm sure there are other windowing systems with it, too. I'd suggest mousegrab. -- Glenn Maynard
Re: Mouse Capture for Canvas
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. If I load a first-person game in a tab, I shouldn't need to click the window to allow the page to capture the mouse. That'll force every game to start with a superfluous box saying click here to start. So right when you go to that tab even just to glance at it your mouse will be grabbed. I want to point out that most FPS games have a menu at the front. But yeah the main problem with just grabbing the mouse is that people just switching through tabs probably don't want their mouse grabbed. That and what happens when a tab isn't in view when capture is called? Also what are your guy's name ideas? I think I prefer mousecapture and mouserelease and just push aside the IE API. Mouse capture isn't just an IE API. There's also a similar Win32 API with the same name, with the same use case as IE's API: to continue receiving mouse motion when dragging. I'm sure there are other windowing systems with it, too. I'd suggest mousegrab. Since grab has no opposite mousegrab doesn't work. (ungrab isn't an English word and let go sounds wrong). After discussing this in the IRC channel for whatwg it seems like mouselock and mouseunlock are recommended. They describe the operation pretty well that the mouse is locked to an element. Anyone have disagreements or other ideas?
Re: Mouse Capture for Canvas
On Wed, Feb 9, 2011 at 9:20 PM, Brandon Andrews warcraftthre...@sbcglobal.net wrote: If I load a first-person game in a tab, I shouldn't need to click the window to allow the page to capture the mouse. That'll force every game to start with a superfluous box saying click here to start. So right when you go to that tab even just to glance at it your mouse will be grabbed. That depends on how it's implemented. (I'd rather not go into specifically how I think browsers might do this--those particular details aren't the point, at least at this stage.) Of course, browsers can still choose to only allow initiating a grab on click, and it can even be codified in the spec if that's what people really want. Again, the point is that it's not necessary to do that in a way that's impossible to change later on. If grabbing the mouse happens by the act of receiving a particular event, then it's impossible to ever relax the restriction without making a whole new API. (I also seriously doubt that any proposal will gain traction that causes merely listening to an event to have side-effects. That's not how DOM events work.) I want to point out that most FPS games have a menu at the front. Try not to make too many assumptions about UIs. A couple more examples: - Depending on clicking on the main menu to grab the mouse is brittle. It means you need to determine *at the time of the click* whether to grab the mouse. For example, if you have start game and options menu items, the menu item itself needs to know to grab the mouse when start game is clicked, but not when options is clicked. That's an ugly, limiting design. - It breaks down in a typical lobby UI. For example, you have a window where people can join a game about to start, set options, chat, etc., with a timer counting down for the game to start. When the timer reaches 0, the lobby UI goes away and the game starts--and everyone's mouse should be grabbed without needing to click the window again. - VMware grabs keyboard and mouse input to redirect it to the VM. You can do this by clicking the window, but you can also do it with a keyboard shortcut (^G), so you can fully grab input with the keyboard alone. This should be allowed from the start: mouse grabbing should be allowed from any input event (other than mousemove), including keyboard events. (Please don't nitpick the individual examples; the point is that there are lots of cases where it makes sense to grab the mouse without it being in response to a click.) But yeah the main problem with just grabbing the mouse is that people just switching through tabs probably don't want their mouse grabbed. That and what happens when a tab isn't in view when capture is called? It fails, as if the user was prompted for permission and clicked no. Since grab has no opposite mousegrab doesn't work. (ungrab isn't an English word and let go sounds wrong). I don't think ungrab is unnatural, but I'm not too concerned with the naming, aside from avoiding capture. -- Glenn Maynard
Re: Mouse Capture for Canvas
On Wed, Feb 9, 2011 at 3:55 PM, Brandon Andrews warcraftthre...@sbcglobal.net wrote: Actually this would be used for both fullscreen and non-fullscreen applications. The reason for this is because it's often CPU intensive to run a complex canvas application in fullscreen. Looking forward not-very-far, canvas will be scaled using the GPU for most users, so this issue should go away. Or, you can put the canvas in the middle of a blank page and make that fullscreen. What are some real use-cases for capturing with the mouse up in non-fullscreen windows? Do a significant number of users want to play mouse-capturing games in non-fullscreen mode? I agree an API to get mouse deltas is needed. I would suggest introducing a completely separate API that lets applications monitor mouse deltas while their window has focus, one that doesn't interact with normal mouse events at all. I don't think requiring a user click on a page to trigger capture is good enough to prevent abuse. It's easy to get users to click on things in the page. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Mouse Capture for Canvas
On Wed, Feb 9, 2011 at 10:52 PM, Robert O'Callahan rob...@ocallahan.orgwrote: What are some real use-cases for capturing with the mouse up in non-fullscreen windows? Do a significant number of users want to play mouse-capturing games in non-fullscreen mode? I'd certainly want to be able to debug them in a window. It applies to non-game uses, too. For example, a common annoyance with Google Maps is when you're dragging the map and your mouse cursor hits the side of the screen, the map stops moving; you have to release the button and reposition the cursor. Mouse grabbing would trivially fix this. Being fullscreen and grabbing the mouse are orthogonal features, though of course browsers could use fullscreen as a factor in deciding whether to honor a request to grab the mouse cursor. They might be more lenient with granting the request in fullscreen. I agree an API to get mouse deltas is needed. I would suggest introducing a completely separate API that lets applications monitor mouse deltas while their window has focus, one that doesn't interact with normal mouse events at all. At least in Windows, it's hard to get deltas without grabbing the mouse. If the mouse cursor is at the right edge of the screen and the user moves the mouse to the right, Windows doesn't report the motion--the clamping happens too early on. Games work around this by hiding the mouse cursor and constantly warping the hidden cursor to the center of the screen, which is probably what browsers would do too. -- Glenn Maynard
Re: Mouse Capture for Canvas
On Thu, Feb 10, 2011 at 5:32 PM, Glenn Maynard gl...@zewt.org wrote: It applies to non-game uses, too. For example, a common annoyance with Google Maps is when you're dragging the map and your mouse cursor hits the side of the screen, the map stops moving; you have to release the button and reposition the cursor. Mouse grabbing would trivially fix this. Sure, but this is not a use-case for capturing while the mouse button is up. At least in Windows, it's hard to get deltas without grabbing the mouse. If the mouse cursor is at the right edge of the screen and the user moves the mouse to the right, Windows doesn't report the motion--the clamping happens too early on. Games work around this by hiding the mouse cursor and constantly warping the hidden cursor to the center of the screen, which is probably what browsers would do too. Hmm, interesting. That might make things nasty indeed. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Mouse Capture for Canvas
On Wed, Feb 9, 2011 at 9:20 PM, Brandon Andrews warcraftthre...@sbcglobal.net wrote: If I load a first-person game in a tab, I shouldn't need to click the window to allow the page to capture the mouse. That'll force every game to start with a superfluous box saying click here to start. So right when you go to that tab even just to glance at it your mouse will be grabbed. That depends on how it's implemented. (I'd rather not go into specifically how I think browsers might do this--those particular details aren't the point, at least at this stage.) Of course, browsers can still choose to only allow initiating a grab on click, and it can even be codified in the spec if that's what people really want. Again, the point is that it's not necessary to do that in a way that's impossible to change later on. If grabbing the mouse happens by the act of receiving a particular event, then it's impossible to ever relax the restriction without making a whole new API. So what you'd prefer would be to allow the mouse to call element.lockMouse(), element.unlockMouse() whenever it wanted. Then assume the user-agent will perform restrictions? These restrictions would be asking the user to allow the action and preventing abuse? Sounds good. This gets rid of the events completely. I want to point out that most FPS games have a menu at the front. Try not to make too many assumptions about UIs. A couple more examples: - Depending on clicking on the main menu to grab the mouse is brittle. It means you need to determine *at the time of the click* whether to grab the mouse. For example, if you have start game and options menu items, the menu item itself needs to know to grab the mouse when start game is clicked, but not when options is clicked. That's an ugly, limiting design. - It breaks down in a typical lobby UI. For example, you have a window where people can join a game about to start, set options, chat, etc., with a timer counting down for the game to start. When the timer reaches 0, the lobby UI goes away and the game starts--and everyone's mouse should be grabbed without needing to click the window again. I can agree with that use-case. Sounds like something to allow. - VMware grabs keyboard and mouse input to redirect it to the VM. You can do this by clicking the window, but you can also do it with a keyboard shortcut (^G), so you can fully grab input with the keyboard alone. This should be allowed from the start: mouse grabbing should be allowed from any input event (other than mousemove), including keyboard events. Assuming that a person can call the lock function whenever in any mouse or keyboard event then there is no initial interaction required. Sounds like what you want, and it would be very flexible. (Please don't nitpick the individual examples; the point is that there are lots of cases where it makes sense to grab the mouse without it being in response to a click.) I won't, but these examples will help to refine and point out problems. I think we're finding a pretty solid solution. But yeah the main problem with just grabbing the mouse is that people just switching through tabs probably don't want their mouse grabbed. That and what happens when a tab isn't in view when capture is called? It fails, as if the user was prompted for permission and clicked no. That works.
Re: Mouse Capture for Canvas
On Wed, Feb 9, 2011 at 11:37 PM, Brandon Andrews warcraftthre...@sbcglobal.net wrote: So what you'd prefer would be to allow the mouse to call element.lockMouse(), element.unlockMouse() whenever it wanted. Then assume the user-agent will perform restrictions? These restrictions would be asking the user to allow the action and preventing abuse? Sounds good. This gets rid of the events completely. The events should still exist, so you can tell if your request was accepted, and you can tell if the browser has locked or unlocked the mouse for other reasons, such as pressing a hotkey to release the mouse. There should probably also be a lockrefused event, to notify that a lock request was rejected. Assuming that a person can call the lock function whenever in any mouse or keyboard event then there is no initial interaction required. Sounds like what you want, and it would be very flexible. This would still require initial interaction; for example, in the lobby timer case, you'd still have to do something--click the screen or press a key--to initiate it. Methods for relaxing that can be explored later. For example (as mentioned just previously) a browser might allow locking the mouse without any interaction if the page is fullscreened, or if the page is acting as a standalone application (eg. an application shortcut in Chrome or a Chromium packaged app). (If this gains any traction, of course--agreeing about something here doesn't automatically make things get implemented. :) -- Glenn Maynard
Re: Mouse Capture for Canvas
On Wed, Feb 9, 2011 at 11:37 PM, Brandon Andrews warcraftthre...@sbcglobal.net wrote: So what you'd prefer would be to allow the mouse to call element.lockMouse(), element.unlockMouse() whenever it wanted. Then assume the user-agent will perform restrictions? These restrictions would be asking the user to allow the action and preventing abuse? Sounds good. This gets rid of the events completely. The events should still exist, so you can tell if your request was accepted, and you can tell if the browser has locked or unlocked the mouse for other reasons, such as pressing a hotkey to release the mouse. There should probably also be a lockrefused event, to notify that a lock request was rejected. Whoops. Forgot to remove that when I was typing my post. I kind of felt like I missed something. The events would be mouselock(event) and mouseunlock(event) now. So both of those would have events. event.successful to see if the mouselock was successful? The event could be called MouseLockEvent. Fits with MouseEvent, KeyboardEvent, WheelEvent (On another note the WheelEvent deltaX and deltaY can be moved to MouseEvent since both are the same data type. The wheel and mousemove event would just use them differently. Might be a poor design decision that will need to be checked out). Does the mouseunlock require an event? (Could you cancel the event?) Assuming that a person can call the lock function whenever in any mouse or keyboard event then there is no initial interaction required. Sounds like what you want, and it would be very flexible. This would still require initial interaction; for example, in the lobby timer case, you'd still have to do something--click the screen or press a key--to initiate it. A query could be implemented ( element.canLockMouse() ) to see if the domain/page is allowed to capture the mouse. If not it could call the element.lockMouse() to initiate the browser's security feature. A browser that doesn't implement any would just return true for allowed. That seems very different from what I've seen in any DOM stuff though.
Mouse Capture for Canvas
The main idea is here in bugzilla: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c4 I'll post it here though since Doug said this might get more people to see it. The idea would be to allow the browser to capture, as in lock the mouse to a certain DOM region such as a canvas tag. Thinking back on this I realized a few things were missing from the initial idea so I'll explain the whole concept in more detail. The MouseEvent would need two new members: deltaX deltaY Which in the mousemove event would be set to the change in the mouse position. So if you move your mouse left 5 pixels deltaX would be set to -5 and if you moved the mouse up 5 pixels deltaY would be set to -5. To keep this as simple as possible a developer would create a canvas tag on their web page then add a mousecapture, mousemove, mouseup, and mousedown event to it. The new mousecapture event would be fired when a user clicked on the element. Unless anyone can think of a reason I don't see why any other tag should be able to use that event. mousecapture would run before click: http://www.w3.org/TR/2010/WD-DOM-Level-3-Events-20100907/#events-mouseevent-event-order In the mousecapture event a user-agent can do whatever it wants to help the user. It could make a small yellow bar like in chrome or firefox and say This website is requesting to capture your mouse. [Allow] [Deny]. If denied the event would never be called. If allowed the event wouldn't be called until the user clicked a second time. The user-agent could handle this how they wanted. A user-agent would also define a key to release mouse capture. (Probably Esc, but there's no need to define it in the standard except as a suggestion). Implementers would be encouraged to display something over the page that says Press key to release mouse capture. With the mousecapture is a mouserelease event which when registered on the same canvas tag responds when the user presses the release key. The event actually does the unregistering. The mouserelease would need to be callable to allow a web page to release control when it wanted, but the mousecapture can't be callable since that would allow someone to capture a mouse without a click. A situation that needs to be handled is alt-tabbing or general loss of focus from a tab or the browser. During these situations the simplest thing to do is to call the mouserelease event. The user would need to click to regain mouse capture. That sums up everything. Obviously it could be implemented differently, but I think I outlined what's needed.
Re: Mouse Capture for Canvas
IE has a setCapture DOM API. We've implemented it in Gecko: https://developer.mozilla.org/en/DOM/element.setCapture Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Mouse Capture for Canvas
This API doesn't handle all of the desired use cases. In particular, to implement Quake-style mouse look (needed for e.g. http://code.google.com/p/quake2-gwt-port/) it needs to work when the mouse button is up, not just down. -Ken On Tue, Feb 8, 2011 at 12:11 PM, Robert O'Callahan rob...@ocallahan.org wrote: IE has a setCapture DOM API. We've implemented it in Gecko: https://developer.mozilla.org/en/DOM/element.setCapture Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Mouse Capture for Canvas
On Tue, Feb 8, 2011 at 5:49 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote: This API doesn't handle all of the desired use cases. In particular, to implement Quake-style mouse look (needed for e.g. http://code.google.com/p/quake2-gwt-port/) it needs to work when the mouse button is up, not just down. How would you satisfy that use-case without enabling abusive behavior by Web sites? Per the proposal posted earlier and at http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 : 1. Only enable mouse capture in response to a user gesture (clicking on the element). 2. Possibly require confirmation from the user to enter mouse capture mode. 3. Present clear UI to indicate how to exit mouse capture mode. -Ken (I think that case would work with our API if the game was full-screen, which I expect it normally would be.) Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Mouse Capture for Canvas
(Not sure how to reply to a mailing list with yahoo mail so this might not work or it might) On Tue, Feb 8, 2011 at 5:49 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote: This API doesn't handle all of the desired use cases. In particular, to implement Quake-style mouse look (needed for e.g. http://code.google.com/p/quake2-gwt-port/) it needs to work when the mouse button is up, not just down. How would you satisfy that use-case without enabling abusive behavior by Web sites? (I think that case would work with our API if the game was full-screen, which I expect it normally would be.) Rob Actually this would be used for both fullscreen and non-fullscreen applications. The reason for this is because it's often CPU intensive to run a complex canvas application in fullscreen. Another key part that Kenneth mentioned was the ability to get deltaX and deltaY of the mouse which is very powerful when you have the mouse locked. In games this allows you to move your mouse to edge of the canvas element and continue to detect mouse changes whereas in a fullscreen application moving your mouse to the left side will lock to 0 for the x mouse position even though the mouse may still be moving left. The deltaX would say like -12 for instance showing the person is still moving left. Hopefully that clears things up.
Re: Mouse Capture for Canvas
On Tue, Feb 8, 2011 at 8:54 PM, Kenneth Russell k...@google.com wrote: How would you satisfy that use-case without enabling abusive behavior by Web sites? Per the proposal posted earlier and at http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 : 1. Only enable mouse capture in response to a user gesture (clicking on the element). This proposal seems to say that mouse capture is enabled by adding an event handler to an element. I don't like this: - It's a major break from the normal event model. Merely defining an event shouldn't cause side-effects. - It permanently bakes the requirement that mouse capture can only happen in response to a click into the API. There are legitimate cases to capture the mouse without first requiring a click. Browsers may not want to allow this, but if they can do so without causing abuse then it should be possible to do so. This is very similar to mouse capture at the OS level, where users needs to be able to escape from misbehaving mouse-capturing applications. It may be worth comparing the interfaces used for that to see if they can be applied to web apps. Also note that as fullscreen and mouse capture often go together, the mouseover the top of the screen mechanisms associated with fullscreen won't work when both are enabled. (I'm not a fan of that UI, either, as they take over the top portion of the screen, preventing UIs from putting menus there.) 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. Note that mouse capture may be the wrong name for this. Mouse capture usually refers to capturing mouse movement even when the mouse leaves the window, usually to implement dragging--this is what IE's mouse capture API is for. This is different--the mouse cursor is typically hidden and locked in place, so mouse motion never hits the boundaries of the screen and clicks never go to another window. It might be better to call this something else to avoid confusion with regular mouse capture; I'd suggest mouse grabbing. -- Glenn Maynard
Re: Mouse Capture for Canvas
On Tue, Feb 8, 2011 at 10:27 PM, Charles Pritchard ch...@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. 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. 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). -- Glenn Maynard
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 ch...@jumis.com mailto:ch...@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.
