6449 - [key]Windows: alt-char sends wrong keycode

Status: VERIFIED FIXED

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

Description

[Akkana Peck]

Short description: on Windows, typing c or alt-c gives an event with a keycode
of 99, while typing shift-c or ctrl-c gives an event with a keycode of 67.
Shouldn't alt and ctrl result in the same keycode (with the flag bits
different?)

Long description and how to reproduce: in the editor in
nsEditorEventListeners.cpp, we have the following (temporary until xpfe provides
keymapping) code:

  if (NS_SUCCEEDED(aKeyEvent->GetKeyCode(&keyCode)) &&
      NS_SUCCEEDED(aKeyEvent->GetShiftKey(&isShift)) &&
      NS_SUCCEEDED(aKeyEvent->GetCtrlKey(&ctrlKey)) &&
      NS_SUCCEEDED(aKeyEvent->GetAltKey(&altKey))
      )
  {
    // XXX: please please please get these mappings from an external source!
    switch (keyCode)
    {
      case nsIDOMEvent::VK_C:
        if (PR_TRUE==ctrlKey)
	  /* does a Copy() */;
        else if (PR_TRUE==altKey)
          /* prints out the column width if you're in plaintext mode */;
    }

This works on linux, but doesn't work on Windows because in the alt case the
keycode mapping is different from the ctrl case.

Is this a misunderstanding on our part, more confusion between keycode and
charcode?  I would expect that keycode would be the same if the key was the
same, while charcode might be different depending on the modifier keys; do I
have that backward?

Comment 1

[Simon Fraser [no longer active]]

cc: tague.

Comment 2

[rods (gone)]

keycodes are incorrect when ALT key pressed. I have added code to convert these
to the proper value to match the the control key values.

Comment 3

[Akkana Peck]

To be a bit clearer: To reproduce, hit alt-C in the plaintext editor (you can
get a plaintext editor via the Tools menu).  It should print to stdout a message
like "Currently wrapping to 80" (or some other number).  If it doesn't print
anything, or inserts a c or some other character into the document, then the bug
isn't fixed.

Comment 4

[Jan Carpenter]

Thanks Akkana, If I leave the cursor where it is when I start the plaintext
editor and press alt-c I don't get anything.  If I move the cursor and try the
alt-c, I get a c.  Marking not fixed for build 1999-06-21-08-M8, and reopening.

Comment 5

[rods (gone)]

I reset the ifdef's to use my old OnChar method and it works fine. Tague has
introduced a bug with his new OnChar code for double-byte chars

Comment 6

[rods (gone)]

Removing akkana from cc list (she is the reporter)

Comment 7

[tague]

this isn't going to make the M8 cutoff, so I'm moving to M9.  If someone wants
to make a case for this, I can try to work on it post-M8 freeze.

Comment 8

[tague]

I'm moving this out since the keyboard event handling stuff is going to need to
get re-written to take into account the decisions made at today's meeting (me,
saari, brade, joki, rods) regarding changing the way keydown v. keypress events
are generated

Comment 9

[Kathleen :Brade]

is this bug invalid given our latest spec?  I think it might still be valid since
we are talking about keycodes...

Comment 10

[Frank Tang]

reassign to ftang per i18ngrp reassignment meeting.

Comment 11

[Frank Tang]

fix in keyEvent_19991004_BRANCH landing

Comment 12

[Akkana Peck]

Jan: the only way I know of to test this with an optimized build is to make a
keybinding to an alt key and see if it works (which is, in any case, the reason
that this bug is important).

The syntax and filenames change every week or so, but right now here's how to do
this:

Edit the file chrome/platformHTMLBindings.xml.
You'll probably see bindings for "inputFields" and "textAreas".
Right under the <binding> line, insert a line that looks like this:
      <handler type="keypress" id="key_end_alt" keycode="e" alt="true"
        command="cmd_endLine"/>
Then run mozilla, click in a text field (e.g. the url bar), type alt-e, and see
if it goes to the end of the line.

Unfortunately, this isn't working for me today; I see a menu popup when I type
alt-e after inserting the above binding, instead of seeing the endLine command. 
Cc'ing hyatt for help.

Comment 13

[Akkana Peck]

Oops, it would help if I actually did cc hyatt.  Hyatt, can you read my last
comment and elaborate on why adding this xbl binding does not successfully
override the menu key?  Thanks!

Comment 14

[Akkana Peck]

Oops, make that key="e", not keycode="e".  But I still see a menu popping up.

Comment 15

[Jan Carpenter]

Thanks!  
This doesn't work for me either.  I get the Edit menu with Paste selected.

Tried on WinNT, Mac, and Linux with same result on all.

Comment 16

[Jan Carpenter]

Correction: On the mac I changed the keybinding as Akkanna noted, except I made 
it to meta instead of alt.  Typing command e resulted in no action at all.

changing platform/os to all/all

Comment 17

[Jan Carpenter]

My mistake, Akkanna says this really is a windows only bug, and that it can't be 
verified until the keybinding stuff is working.  Changing back to WinNT/PC and 
resolved fixed but not verified.... 

Comment 18

[Akkana Peck]

Actually, it turns out that it probably should be reopened.  I put a printf in
nsXBLEventHandler.cpp (just as a handy place that I knew was tracking KeyPress)
and discovered that on Windows, we never actually get the event when I press the
alt key.  On Unix, we get the event for alt but not for control.

But I thought, maybe someone else is eating the key event.  So I turned on
#define KE_DEBUG in windows/nsWindow.cpp, and sure enough, for alt, there's a
KeyDown and a KeyUp generated, but we don't generate a KeyPress at all.

Is my memory failing me?  Did we decide we didn't want KeyPress after all on
modifier keys?

Comment 19

[Frank Tang]

akkana: I don't understand why  you reopen this bug. The summary of the 
origional bug say "alt-char send wrong keycode". Currently, it did send the 
right key code in the keypress of the "alt-char" . I send KeyUp/KeyDown for the 
Alt also. It does not send KeyPress for Alt but that is not same as the 
origional bug. And how important to send KeyPress for ALT along is totally a 
different priority of the origional bug. 

Please do not recycle bug report. 

does       <handler type="keypress" id="key_end_alt" keycode="e" alt="true"
in xbl mean pressing 'e' WHILE alt is pressed or pressing 'e' AFTER alt is 
pressed ?

Comment 20

[Akkana Peck]

It's not sending any keycode at all now for key press, as far as I can tell;
that's not exactly the same as sending the wrong keycode, but it's close enough
that it seemed worth it to reopen the same bug.  If you would prefer a separate
bug for some reason, feel free to close this one and open another one (but of
course, this one cannot be verified until the other one is fixed since if it
doesn't send any keycode, then it obviously isn't sending the correct keycode).

alt="true" in a keybinding means while alt is pressed.  But at this point the
keybinding is moot; the problem is that the Windows backend code doesn't seem to
generate any key event at all for KeyPress of alt.  Setting the alt bit in the
keypress event for the 'e' may be handled differently.

Comment 21

[bobj]

Cleared M11 TM, since this is a reopened bug.

Comment 22

[Frank Tang]

I really have no idea why sending KeyPress for ALT itself is related to this 
problem. The importnat thing is we do send KeyPress when the 'e'of the Alt-e is 
pressed, and teh IsAlt is set in that KeyPress. Why the lack of KeyPress for ALT 
itself will cause this problem in the XBL ? 

>It's not sending any keycode at all now for key press
This is not true. It send ONE KeyPress for the 'e' of the Alt-e. It didn't send 
the KeyPress for the ALT itself. 

Comment 23

[David Hyatt]

This bug should be closed.  ALT+e not working is a different issue.  Please file 
a completely separate bug on this to me.  It's related to event ordering between 
the menu listener and XBL.

Comment 24

[Akkana Peck]

Discussed this with Kathy.  We'll keep this bug closed and opening new ones on
the existing issues.

Filed bug 26261 to Hyatt on xbl alt bindings not working.
Filed bug 26262 to Frank on the alt key (or other modifiers) alone not working.
Kathy says the mac also needs a bug on modifier keys not generating KeyPress;
I'll let her file that.
The keycode generated for the 'e' keypress (as opposed to the nonexistant alt
keypress) on alt-e is fine, so I'll mark this verified since there's no easy way
for QA to test it.