Closed Bug 2213 Opened 26 years ago Closed 26 years ago

Key handling needs fixing

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P2)

PowerPC
All
defect

Tracking

()

VERIFIED DUPLICATE of bug 3511

People

(Reporter: sfraser_bugs, Assigned: sdagley)

Details

There are a number of issues with key handling that need fixing: 1. There is no field in nsKeyEvent to say whether the command key is down 2. Command keys that have no menu equivalents are lost, whereas they need to propagate down the the key listener (e.g. for undo in the editor) 3. There is a bunch of weird key handling code in nsEditorKeyListener::GetCharFromKeyCode() that needs fixing for the different platforms. 4. The hard-coded list of key types in nsIDOMEvent.h seems to preclude the handling of keys not in this list. We need a way to handle input of any char that the system allows.
Assignee: sdagley → pierre
Reassigning to pierre with the expectation he'll need to bug joki
About #1: When the command key is down, the application calls HandleMenuCommand() instead of HandleOSEvent() and no nsKeyEvent is generated. So the nsKeyEvent doesn't need a flag for the command key. About #2: As in all Mac applications, command keys without menu equivalents are lost. If you need to implement Undo as Cmd-Z in the editor, add a menu item "Undo = Cmd-Z" and listen to the nsMenuEvent: its 'mCommand' field contains the Mac menuResult.
How are we going to handle a command-click in the current scheme, if we don't know whether the command key was down? Do we have to look in the platform- specific event data? Command-click is used for discontiguous list selection in widgets, for example.
Right: when I first saw the declaration of nsInputEvent, I considered it was ok not to have a flag for the Command key since it was available on Mac only and we could still look into nsMouseEvent.nativeMsg. On a second thought, there is no reason not to add it. Joki, what do you think? Can we add 'isCommand'?
Yeah, we certainly can add it. But I'd like to avoid having the nsInputEvent struct grow too big if we can. Can we get a union of these key types for what keys exist or don't exist on Mac/Unix/Windows?
how would we get such a list? who would be able to generate it?
I can obtain this data from 4.5. Would that help?
joki is referring to the control/alt/command keys, not key shortcuts used by communicator. It just needs someone for each platform to identify their modifier keys. Here's a start: Mac: Shift, Option (=Alt), Control, Command, (Caps lock) Windows (I'm guessing): Shift, Alt, Control, (Caps lock), and on my HP keyboard I also see: Windows key, Contextual menu key.
Assignee: pierre → sfraser
OS: All
Summary: [PP] Key handling needs fixing → Key handling needs fixing
I added 'isCommand' in nsInputEvent for the Mac only. It's only used in Widget, not in nsIDOMEvent.h or nsJSEvent.cpp. This, as well as issues #3 and 4, can be fixed by the Editor team when time comes and if it appears to be a problem. For now, I'm considering #1 fixed, #2 invalid, #3 and #4 as potential issues for the Editor only so I'm removing the [PP] tag and reassigning to Simon.
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
See also bug 3511.
QA Contact: 4015 → 3847
QA contact re-assigned according to the product areas we're currently working on.
Assignee: sfraser → sdagley
Status: ASSIGNED → NEW
Reassign to sdagley, who owns this for now. You may want to close this as a dup of 3511.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 3511 ***
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.