Closed
Bug 91592
Opened 23 years ago
Closed 6 years ago
Inconsistent keydown repeat behavior across platforms
Categories
(Core :: Widget: Win32, defect)
Core
Widget: Win32
Tracking
()
RESOLVED
DUPLICATE
of bug 597981
People
(Reporter: jruderman, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file)
189 bytes,
text/html
|
Details |
nsMenuBarListener gets a KeyDown event along with each KeyPress event generated from autorepeat. As a result, if Alt is held down for a long time, the listener thinks it's being pressed repeatedly, which results in the menu bar getting focus in several cases when it shouldn't. Steps to reproduce: 1. Apply my third patch in bug 79898. 2. Press Alt to focus the menu bar. 3. Press Alt to remove focus from the menu bar, but hold it for a few seconds before releasing it. or 1. Apply my third patch in bug 79898. 2. Alt+click on an empty area of the content area. 3. Continue holding Alt for another few seconds. Result: menu bar gets focus. This prevents us from using Alt+click for anything on Win32. (Alt+click would probably be used for something unimportant, or as a synonym for Ctrl+Shift+click, because Alt+click is reserved on some Linux systems for moving windows around.)
Comment 1•23 years ago
|
||
Yeah, this is irritating. Looking at for 1.0
Target Milestone: --- → mozilla1.0
Comment 2•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Updated•22 years ago
|
QA Contact: madhur → rakeshmishra
Reporter | ||
Comment 3•22 years ago
|
||
Reporter | ||
Updated•22 years ago
|
Summary: nsMenuBarListener gets KeyDown events for autorepeated keypresses → KeyDown fires for autorepeated keypresses
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 6•20 years ago
|
||
In OnKeyDown I changed BOOL result = DispatchKeyEvent(NS_KEY_DOWN, 0, virtualKeyCode, aKeyData); to BOOL result = (aKeyData & (1 << 30)) || DispatchKeyEvent(NS_KEY_DOWN, 0, virtualKeyCode, aKeyData); Does anyone know if there's an existing constant for that 1 << 30? Also, is || a good idea or should I be using !(aKeyData & (1 << 30)) &&?
Component: Event Handling → Widget: Win32
Comment 7•20 years ago
|
||
Neil, I think we should leave this as is and fire keydown for all repeated keypresses. This will make us in-line with IE. We can't generally use onkeypress in HTML apps, because IE doesn't fire it for any non-printable keys. So, if you want to create an accessible DHTML menubar you need to use onkeydown. If we fix this then autorepeat will work in the DHTML menubar in IE, but not in Mozilla. I think this bug should be to make keydown autorepeat for all Mozilla platforms.
Keywords: access
Comment 8•20 years ago
|
||
Here's what IE does: To start with, the only keys that get keypress in IE are printable keys. So right developers need to use onkeydown if they want the convenience of declarative syntax instead of using addEventListener. IE repeats onkeydown. For onkeypress. it also repeats if it is getting fired (again, it onkeypress is only fired for printable keys). Here's what Mozilla does: We fire onkeypress for all keys, not just printable keys. We repeat both onkeydown and onkeypress on Windows, but not on all platforms. On some platforms we only repeat onkeypress. I haven't gone through and test/analyzed code to see where we differ and where we don't. For quirks mode we should do what IE does, but we should be the same on all platforms. Bug 167145 is related -- make preventDefault for an onkeydown also preventDefault for the onkeypress -- that's another IE compatibility item. If we fix all of these to be the same as IE in quirks mode, we'll make writing keyboard usable DHTML widgets a lot easier. More notes on IE/Mozilla differences and how one has to make keyboard usable DHTML widgets is here: http://www.mozilla.org/access/keyboard/tabindex
Reporter | ||
Updated•19 years ago
|
Assignee: saari → win32
Target Milestone: Future → ---
Comment 9•18 years ago
|
||
Still an important bug.
Assignee: win32 → mats.palmgren
OS: Windows NT → All
Hardware: PC → All
Summary: KeyDown fires for autorepeated keypresses → Inconsistent keydown repeat behavior across platforms
Comment 10•17 years ago
|
||
Developing a webpage this bug really bugs me :-) However is there a reliable way to test in javascript, that repeat is broken? Since then I can just hand-simulate repeats with timers, until receiving the keyupevent. However if one simulates repeats, while really getting repeats from the browser also breaks things up!
Updated•15 years ago
|
QA Contact: ian → win32
Comment 11•14 years ago
|
||
I suppose https://bugzilla.mozilla.org/show_bug.cgi?id=526779 duplicates this one.
Comment 12•14 years ago
|
||
In my app (http://checkvist.com) I use keydown event to handle all the keyboard. I have keyboard navigation on the list (with arrows Up/Down). On Windows, multiple 'keydown' events are generated, and I can go up/down in the list. But on Mac/Linux, only one keydown event is generated (Firefox 3.6.3). So, to go up/down I have to press up/down keys multiple times. _Very_ annoying. Unfortunately, I cannot use keypress event for this (because of multiple problems with FF and other browsers).
Updated•13 years ago
|
Assignee: matspal → nobody
Comment 14•6 years ago
|
||
I believe this is fixed as of bug 597981 and bug 597987 being fixed, right?
Well, must be bug 597981. See also https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Auto-repeat_handling
Flags: needinfo?(masayuki)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•