Open Bug 873874 Opened 8 years ago Updated 2 years ago
Modified mousedown events blocked, polluted, or misreported
I develop interactive pointer-driven applications, where the mousedown and dblclick listeners do additional method dispatch based on keyboard modifiers and mouse button selection. Ideally, with three mouse buttons, four keyboard modifiers and single or double clicks, I should be able to use 112 combinations. I understand that some combinations are intercepted by the OS GUI and nothing can realistically be done about that, but it is frustrating to run into additional limitations imposed by the browser. The purpose of browser technology today is to enable us to create interactive applications. Instead, we are forced to interact with the browser. I believe many of these interactions are needless, while those that may be of use to some users should be optional. Examples: 1. Unavoidable: Double-Button3 -- blocked by all operating systems I tested on; obviously, not Mozilla's fault. 2. Blocked without a good reason: Shift+Button3 -- invokes the context menu but does not fire the contextmenu event and is not preventable. There are several combinations that invoke the context menu besides the expected Button3, which works correctly and is preventable. Please see all events marked "menu not preventable" in the attached table, bigmac-firefox-mouse.pointer-input 3. Polluted: Ctrl+Shift+Button3 -- the mousedown event is fired and the application code works correctly, but the context menu shows anyway, interfering with user input and blocking the view. The contextmenu event is not fired and so cannot be prevented. Such events are marked "blocked-other" in the results table. 4. Misreported: Ctrl+Button1 -- reported as Ctrl+Button3. All input combinations containing Ctrl and Button1 have Button1 replaced with Button3. Marked as "failed". This only happens in OSX; that's why I am reporting this issue against Mac OS X, but #2 and #3 occur in various linux WMs as well. In total, there are 43 blocked, failed, or polluted combinations in the OSX version of Firefox, including the most convenient ones such as Ctrl+Button1 and Ctrl+Shift+Button1. The linux version is similar, except it does not do the Button1 -> Button3 substitution in the presence of Ctrl-key. There are only 24 such failures in Webkit, of which 16 are due to the OS. In the attached archive, pointer-input.xhtml is the test that I use to explore the available input combinations. It is based on YUI, but I have verified that the raw events contain the same information. Both v.20 and v.21 have been tested with identical results.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.