Closed Bug 12497 Opened 21 years ago Closed 21 years ago

Need policy on char codes for modifier keys

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: joki)

Details

A recent checkin switched editor events from KeyDown to KeyPress events, and
that means that now we're getting char codes instead of key codes.  This is fine
for everything except alt keys, for which the char codes are different on all
platforms so there's no way to write XP code which recognizes them.  The
platforms can't write their event code because there's no spec for what they
should be doing (which is why they're all different -- everybody had to guess
and they all guessed a different way).

The fundamental question which needs to be solved is: when a modifier key is
down, should the char code reflect the lower case value of the key, or the upper
case?  And should it be different depending on whether the shift key is pressed?

Personally, I would argue for making the char code follow the shift key, i.e.
alt-a gives a char code of a, alt-shift-a gives a char code of A as well as
having the shift modifier bit set; and that also, alt-2 gives a char code of 2,
alt-shift-2 gives a char code of @ (assuming that's what's above the 2 on the
keyboard being used).

But whether or not you choose to follow that recommendation, the important thing
is that we need a policy one way or the other so that we can make alt key events
work again.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
In the absence of a policy, I have chosen one (with Kathy and Shaver's
agreement, and after checking with hyatt and saari), which is the one already
outlined in this bug; and I have checked in the changes to the gtk event
handler, and a minor change for the alt-x case to the editor hardwired bindings.
I've filed bugs against Mac and NT to fix their char code generation
accordingly.
Well I agree with the policy.  I'll have to figure out the correct
implementation on Windows.  Currently on Windows at least we get a translated
character based on the key hit but only when hitting Ascii characters.  When
hitting non-Ascii characters no WM_CHAR event (the Windows event we key
Keypress event off of) is generated.  This could be tough to do.
Keywords: verifyme
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
VERIFIED ON BUILD 2001-07-30-08-TRUNK
Status: RESOLVED → VERIFIED
Keywords: verifyme
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.