Closed Bug 91592 Opened 19 years ago Closed 2 years ago

Inconsistent keydown repeat behavior across platforms

Categories

(Core :: Widget: Win32, defect)

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 597981

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file)

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.)
Yeah, this is irritating.  Looking at for 1.0
Target Milestone: --- → mozilla1.0
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
QA Contact: madhur → rakeshmishra
Blocks: 71074
Summary: nsMenuBarListener gets KeyDown events for autorepeated keypresses → KeyDown fires for autorepeated keypresses
QA Contact: rakeshmishra → trix
.
Assignee: joki → saari
QA Contact: trix → ian
retargeting
Target Milestone: mozilla1.0.1 → Future
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
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
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
Assignee: saari → win32
Target Milestone: Future → ---
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
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!
QA Contact: ian → win32
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).
Duplicate of this bug: 526779
Assignee: matspal → nobody
I believe this is fixed as of bug 597981 and bug 597987 being fixed, right?
Depends on: 597981, 597987
Flags: needinfo?(masayuki)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 597981
You need to log in before you can comment on or make changes to this bug.