Key handling needs fixing

VERIFIED DUPLICATE of bug 3511

Status

()

Core
Event Handling
P2
normal
VERIFIED DUPLICATE of bug 3511
19 years ago
19 years ago

People

(Reporter: Simon Fraser, Assigned: Steve Dagley)

Tracking

Trunk
PowerPC
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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)

Updated

19 years ago
Assignee: sdagley → pierre
(Assignee)

Comment 1

19 years ago
Reassigning to pierre with the expectation he'll need to bug joki

Comment 2

19 years ago
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.
(Reporter)

Comment 3

19 years ago
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.

Comment 4

19 years ago
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'?

Comment 5

19 years ago
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?

Comment 6

19 years ago
how would we get such a list?  who would be able to generate it?

Comment 7

19 years ago
I can obtain this data from 4.5.  Would that help?
(Reporter)

Comment 8

19 years ago
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.

Updated

19 years ago
Assignee: pierre → sfraser
OS: All
Summary: [PP] Key handling needs fixing → Key handling needs fixing

Comment 9

19 years ago
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.
(Reporter)

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 10

19 years ago
Setting all current Open/Normal to M4.

Comment 11

19 years ago
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
(Reporter)

Comment 12

19 years ago
See also bug 3511.

Updated

19 years ago
QA Contact: 4015 → 3847

Comment 13

19 years ago
QA contact re-assigned according to the product areas we're currently working
on.
(Reporter)

Updated

19 years ago
Assignee: sfraser → sdagley
Status: ASSIGNED → NEW
(Reporter)

Comment 14

19 years ago
Reassign to sdagley, who owns this for now. You may want to close this as a dup
of 3511.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 15

19 years ago
*** This bug has been marked as a duplicate of 3511 ***

Updated

19 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.