Last Comment Bug 44259 - [key] Mac is sending 0 keycodes for some keys (keydown/keyup)
: [key] Mac is sending 0 keycodes for some keys (keydown/keyup)
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Widget: Cocoa (show other bugs)
: Trunk
: All Mac OS X
P3 major with 1 vote (vote)
: mozilla1.9alpha8
Assigned To: Josh Aas
:
: Markus Stange [:mstange]
Mentors:
http://www.w3.org/TR/1999/WD-DOM-Leve...
: 300678 (view as bug list)
Depends on:
Blocks: tibco 448434
  Show dependency treegraph
 
Reported: 2000-06-29 14:31 PDT by Kathleen Brade
Modified: 2008-07-29 13:39 PDT (History)
18 users (show)
jaas: blocking1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Here is the test page. You will see if you are on mac and press Alt+7 it says 0 instead of 55 (404 bytes, text/html)
2003-03-04 14:29 PST, sursur14
no flags Details
KeyEvent viewer w/ modifiers (1.54 KB, text/html)
2006-11-21 12:11 PST, Jim
no flags Details
JavaScript code converts Event.keyCode to a String (3.00 KB, application/x-javascript)
2007-05-16 15:56 PDT, Jesse Costello-Good
no flags Details
fix v1.0 (11.29 KB, patch)
2007-06-14 17:46 PDT, Josh Aas
no flags Details | Diff | Splinter Review
fix v1.0.1 (13.88 KB, patch)
2007-06-14 18:30 PDT, Josh Aas
no flags Details | Diff | Splinter Review
fix v1.1 (14.09 KB, patch)
2007-06-15 18:56 PDT, Josh Aas
nick.kreeger: review+
bugs: review-
Details | Diff | Splinter Review
fix v2.0 (9.33 KB, patch)
2007-06-27 22:38 PDT, Josh Aas
nick.kreeger: review+
mikepinkerton: superreview+
Details | Diff | Splinter Review

Description User image Kathleen Brade 2000-06-29 14:31:58 PDT
Based on Rods' example (see url above), I can see that the Mac isn't always 
sending a keycode for some keys for keydown/keyup events.
Here are a few of the keys which don't work:
  shift-1 thru shift-0
  -, shift--
  shift-=
  shift-\
  shift-/
  shift-.
  shift-,
  shift-`
  any key with the option modifier
Comment 1 User image rubydoo123 2000-07-10 16:49:39 PDT
setting to m18
Comment 2 User image rubydoo123 2000-07-19 09:31:37 PDT
this is related to the other key event issues, providing the correct key event 
functions for users is critical
Comment 3 User image rubydoo123 2000-07-27 07:11:36 PDT
setting to nsbeta3+
Comment 4 User image rubydoo123 2000-07-31 16:20:05 PDT
adding priority to status whiteboard, not *that* complicated but it'll take time 
to get it right
Comment 5 User image Kathleen Brade 2000-08-04 13:42:58 PDT
reassign to akkana; akkana--we probably need to do something hacky like create a 
table similar to how gtk works.  I don't have any other ideas.  :-/
Comment 6 User image Akkana Peck 2000-08-04 16:07:55 PDT
Actually, joki recently gave me the go-ahead to put those missing symbols into
nsGUIEvent/nsIDOMKeyEvent.  I'm hoping to overhaul those files soon (so we only
have the list of keycodes in one place!), and if I have time, I'll also change
the linux key event code, and, if I can figure out how :-), I'll also do the mac
event code, which would be the best fix to this bug.
Comment 7 User image Akkana Peck 2000-08-22 15:33:39 PDT
Per beppe: setting this to nsbeta3- and reassigning back to brade.
Comment 8 User image rubydoo123 2000-09-18 15:23:27 PDT
this is correctness of events, low risk fix
reviewed by Bijal and beppe, setting to nsbeta3+, p2
Comment 9 User image selmer (gone) 2000-09-19 22:47:08 PDT
pdtp4.  It's not clear there is any user visible impact for this bug.  If it
exists and is merely obscure, please clarify and bring it back to the pdt.
Comment 10 User image rubydoo123 2000-09-20 10:49:40 PDT
on the mac many key events do not work, if it is acceptable for key events to
not work on the mac -- see the first entry in this bug -- then please remark as
pdt priority of your choice and future it. Personally, my opinion is that is a
grave mistake.
Comment 11 User image Akkana Peck 2000-09-20 12:45:27 PDT
Incidentally, we're expecting char codes for these characters, not key codes,
right?  All the examples given are printable characters.
Comment 12 User image rubydoo123 2000-09-25 14:20:39 PDT
setting to nsbeta3- and setting to future, there are menu items that can be
used, which is a viable workaround
Comment 13 User image Steve Dagley 2001-02-20 21:27:52 PST
To paraphrase someone, the future is now.  Can we revisit this bug and figure out 
if it's going to make the next train?
Comment 14 User image sairuh (rarely reading bugmail) 2001-02-21 11:09:01 PST
okay, clearing the milestone so that we reconsider this.
Comment 15 User image Kathleen Brade 2001-02-21 11:16:38 PST
probably won't make this train unless someone else picks it up; milestone-->
Future
Comment 16 User image rubydoo123 2002-03-08 12:07:11 PST
removing myself from the cc list
Comment 17 User image Greg K. 2002-10-20 11:47:45 PDT
Any relation to bug 111335, bug 148130? Does this block bug 122479?
Comment 18 User image Kathleen Brade 2002-10-21 06:51:01 PDT
This bug is about the keydown and keyup events on Mac sending a 0 keycode
instead of the proper value.  The event is still being sent (not that I've
verified lately).

Bug 111335 is about the events not being received at all.  If that is true, it
will block verification of this bug since you need to see the event before you
can look at the keycode for it.

This particular bug is unrelated to bug 122479 (accesskey usage on Mac). 
Accesskey modifier is "Control" and this bug is about shifted key events. 
(Possibly both are blocked by 111335?)
Comment 19 User image sursur14 2003-03-03 16:39:02 PST
This bug is effecting all peoplesoft customers on mac os. Since many of our 
users jobs require data entry, having hot keys is a major plus for them. Since 
we cannot get the keycode with the alt key now means that none of out hot keys 
will work on NS 7 on mac. Do we know when this is planned to be fixed. Is there 
a workaround we could use. 
Comment 20 User image Kathleen Brade 2003-03-04 07:39:55 PST
Eamon_Gaffney@peoplesoft.com (comment 19):
By "hot keys" do you mean accesskeys like for forms?  On the Mac, those are
accessed with Control key not the alt key.  If you have a
case where the accesskeys don't work on Macintosh, please file a new mozilla bug
with the url or a sample html file and cc me (brade@netscape.com).
Comment 21 User image sursur14 2003-03-04 08:49:12 PST
hi brade
your question was "what do I mean by access keys"
I mean that our system has a number of hot keys to allow users to, say, add a 
new row with the Alt+7 button. However no matter what combination I tried the 
evt.keycode always returns 0 and as a result this makes it difficult to resolve 
what key the user pressed. 
Comment 22 User image Kathleen Brade 2003-03-04 08:58:46 PST
Eamon_Gaffney@peoplesoft.com (comment 21): you could try looking at the keyevent
on keypress instead of keydown (looking at event.charCode).  Perhaps paste in a
snippet of your html/js?
Comment 23 User image sursur14 2003-03-04 14:29:47 PST
Created attachment 116231 [details]
Here is the test page. You will see if you are on mac and press Alt+7 it says 0 instead of 55

save this file as  a html and view in NS 7 on mac. You will see that when you
press alt+7 the alert message says the keycode is 0 it should be 55 if you try
in windows env.
Comment 24 User image Simon Paquet [:sipaq] 2003-09-08 04:21:21 PDT
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
Comment 25 User image Karsten Düsterloh 2006-03-11 07:11:47 PST
This is still an issue on Mac OS X 10 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060304 SeaMonkey/1.5a].
Comment 26 User image Karsten Düsterloh 2006-03-11 07:39:12 PST
*** Bug 300678 has been marked as a duplicate of this bug. ***
Comment 27 User image Jim 2006-11-21 12:11:57 PST
Created attachment 246186 [details]
KeyEvent viewer w/ modifiers

I've been using this doc to see KeyEvent values. As it stands, just using 'Shift' w/ a key does not work. This page works reasonably well w/ Safari/Firefox.

Cheers,
Jim
Comment 28 User image Chris Blouch 2007-05-16 13:27:10 PDT
Still happening in Mac 10.4/Intel Gecko 20070309 Firefox 2.0.0.3. Any modifier key combined with number keys row 

`1234567890-=

reports keycode 0 on a keydown event. Was attempting to use for accessibility shortcuts via a generalized keystroke to function/method mapping system.
Comment 29 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2007-05-16 13:55:09 PDT
-> Default Asignee

This has sat for long enough. Josh, is this going to be an issue with the new Cocoa key handling?
Comment 30 User image Josh Aas 2007-05-16 14:43:41 PDT
This still happens under Cocoa.
Comment 31 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2007-05-16 14:52:27 PDT
Changing component, then, and requesting blocking1.9. I know this affects the TIBCO General Interface toolkit, possibly others.

Jesse, can you comment on the difficulties this bug causes so that drivers can triage properly?
Comment 32 User image Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-05-16 15:27:37 PDT
See also bug 308565 and bug 192935.
Comment 33 User image Jesse Costello-Good 2007-05-16 15:55:54 PDT
The mission of TIBCO General Interface is to web applications with the look and feel of desktop graphical user interface application. To that end, we implement many features typically found in Windows and Mac OS X, such as key accelerators. For example, when you type Ctrl+S in the GI IDE, the component you are working on is saved. We have been able to implement key accelerators on Internet Explorer and Firefox for Windows without a problem. We capture the keydown event and look at the keyCode field of the event object. We use code that I'll add as an attachment (keyCodeToString.js). The problem is that on Firefox on Mac OS X, some keys are reported incorrectly. For example ctrl+. is reported as ctrl+n. (See https://bugzilla.mozilla.org/show_bug.cgi?id=44259). Moreover, the mapper error from key to keyCode is not recoverable because ctrl+. and ctrl+n report the same keyCode value. 

Comment 34 User image Jesse Costello-Good 2007-05-16 15:56:59 PDT
Created attachment 265057 [details]
JavaScript code converts Event.keyCode to a String
Comment 35 User image Josh Aas 2007-06-14 17:46:22 PDT
Created attachment 268446 [details] [diff] [review]
fix v1.0

This fixes a whole bunch of key codes, almost everything in this bug plus a bunch more. I didn't fix the ones that don't have a clear definition according to DOM specs.
Comment 36 User image Josh Aas 2007-06-14 18:30:04 PDT
Created attachment 268451 [details] [diff] [review]
fix v1.0.1

oops, I forgot to diff part of the patch
Comment 37 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2007-06-14 19:17:36 PDT
Comment on attachment 268451 [details] [diff] [review]
fix v1.0.1

>     default:
>       if (aKeyEvent->isControl)
>         charCode += 64;

Is this still necessary now that you use charactersIgnoringModifiers? Did that break Control-key handling?

>+          if (charCode >= 'a' && charCode <= 'z') // lowercase
>             geckoKeyCode = toupper(charCode);
>           else if (charCode >= 'A' && charCode <= 'Z') // uppercase
>             geckoKeyCode = charCode;

I know you didn't write this, but couldn't you optimize this function by moving the common ASCII char cases to the top of the function?
Comment 38 User image Josh Aas 2007-06-15 18:56:20 PDT
Created attachment 268569 [details] [diff] [review]
fix v1.1

This removes the nasty control key logic ben mentioned because that causes some bugs and looks like a mistake made back in the original event branch back in 1999.

This also adds support for colon.
Comment 39 User image Nick Kreeger 2007-06-15 18:59:57 PDT
Comment on attachment 268569 [details] [diff] [review]
fix v1.1

Looks good to me. Josh and I couldn't think of a reason the +64 call was there. When we looked up the blamelog, that code landed in 1999.
Comment 40 User image Akkana Peck 2007-06-15 19:26:18 PDT
Not code I'm familiar with (I don't know cocoa key events) but the +64 is presumably because ctrl + A (ascii 65) is ascii 1, and so on.
Presumably this is no longer needed for the current code, if it's already getting a char code of A rather than 1 from the native key event.
Comment 41 User image David Baron :dbaron: ⌚️UTC-8 2007-06-16 00:58:56 PDT
I'm not an appropriate reviewer for this -- you should probably ask jst or smaug.
Comment 42 User image Josh Aas 2007-06-26 21:38:24 PDT
I put the URL for the spec I was basing my key event values on in the URL field of this bug.
Comment 43 User image Josh Aas 2007-06-26 21:46:03 PDT
Another note on my choice of DOM key code values - I checked with IE, WebKit and Opera and Opera seems to be the only browser that doesn't just assign seemingly random numbers to anything beyond alphanumeric keys. Thus, I made sure my work matched up as closely as possible with Opera's implementation, and their implementation matches the WD DOM 2 spec pretty closely.

IE and WebKit don't match up with each other or Opera or the WD spec, as far as I can tell they just made up their own key codes.
Comment 44 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2007-06-27 01:33:22 PDT
Comment on attachment 268569 [details] [diff] [review]
fix v1.1

Opera gives the same 0x2d for INSERT as we do currently, so I wouldn't change it.
(Tested on Linux/trunk and Opera 9.2)

(And as far as I see, Opera doesn't follow the old DOM 2 WD elsewhere either. For example pressing '+' in the keypad gives 0x2b, not 0x6B nor 0x0209)

And if you add support for new VK_s, those should be, IMO, supported in all major platforms, if possible.
And http://lxr.mozilla.org/seamonkey/source/content/xbl/src/nsXBLPrototypeHandler.cpp#606 should be updated too.

Slightly modified test http://mozilla.pettay.fi/moztests/showkeys.html
Comment 45 User image Josh Aas 2007-06-27 22:38:17 PDT
Created attachment 270134 [details] [diff] [review]
fix v2.0

This is very similar to the patch from before, but I am not trying to support key codes that aren't already supported in gecko. I think we should file separate bugs for any particular key codes not fixed by this patch.
Comment 46 User image Nick Kreeger 2007-06-28 07:19:32 PDT
Comment on attachment 270134 [details] [diff] [review]
fix v2.0

Looks good to me.
Comment 47 User image Mike Pinkerton (not reading bugmail) 2007-06-29 09:12:37 PDT
Comment on attachment 270134 [details] [diff] [review]
fix v2.0

sr=pink

did you test the charactersIgnoringModifiers change on non-roman languages and languages with accents (french, spanish, etc)?
Comment 48 User image Jesse Costello-Good 2007-06-29 09:19:04 PDT
Hi, the following key codes work on Internet Explorer and Fx for Windows and Fx for Mac when no modifier keys are held down:

  Event.KEY_ALT = 18;
  Event.KEY_ARROW_DOWN = 40;
  Event.KEY_ARROW_LEFT = 37;
  Event.KEY_ARROW_RIGHT = 39;
  Event.KEY_ARROW_UP = 38;
  Event.KEY_BACKSPACE = 8;
  Event.KEY_CONTROL = 17;
  Event.KEY_DELETE = 46;
  Event.KEY_END = 35;
  Event.KEY_ENTER = 13;
  Event.KEY_ESCAPE = 27;
  Event.KEY_HOME = 36;
  Event.KEY_INSERT = 45;
  Event.KEY_PAGE_DOWN = 34;
  Event.KEY_PAGE_UP = 33;
  Event.KEY_SHIFT = 16;
  Event.KEY_SPACE = 32;
  Event.KEY_TAB = 9;
  Event.KEY_0 = 48;
  Event.KEY_9 = 57;
  Event.KEY_A = 65;
  Event.KEY_Z = 90;
  Event.KEY_F1 = 112;
  Event.KEY_F15 = 126;
  Event.KEY_NP0 = 96;  // number pad key variants
  Event.KEY_NP9 = 105;
  Event.KEY_NPDIV = 111;
  Event.KEY_NPMUL = 106;
  Event.KEY_NPSUB = 109;
  Event.KEY_NPADD = 107;
  Event.KEY_NPDEC = 110;
  
Comment 49 User image Josh Aas 2007-06-29 20:27:28 PDT
landed on trunk

I did some testing on Japanese and accented characters and it worked fine.
Comment 50 User image Jan Wolter 2008-06-23 19:38:50 PDT
I've been watching this bug on and off for eight years now and just tested it in the recently released Macintosh version of Firefox 3.0. Sorry guys, it is only partially fixed.

Zero keycodes are still returned for
shift-- (_)
shift-` (~)
shift-\ (|)
shift-, (<)
shift-. (>)
shift-/ (?)
shift-; (:)

In addition, though shift-= (+) no longer returns a zero keycode, it now returns an incorrect keycode, 107 instead of 61.  From the response above, I guess this is the keycode for the number pad plus key, not the keyboard plus key.

Keys typed with ALT do work now, as do all the shifted number keys and the unshifted - key.
Comment 51 User image Greg K. 2008-07-27 05:55:34 PDT
Reopening per comment 50. The testcase attachment 246186 [details] continues to demonstrate the problems Jan describes.
Comment 52 User image Samuel Sidler (old account; do not CC) 2008-07-27 18:11:35 PDT
Greg, Jan: I think you should open a new bug for that. It sounds like a regression since this apparently was working a year ago.
Comment 53 User image Greg K. 2008-07-29 09:19:14 PDT
(In reply to comment #52)
> Greg, Jan: I think you should open a new bug for that. It sounds like a
> regression since this apparently was working a year ago.

I don’t think it’s a regression. Josh landed the fix on trunk on 2007-06-29. The earliest Mac GranParadiso build that contains the fix (2007080209/3.0a7) still fails the cases in comment 50.

Anyway, if you still think it should be filed as a new bug let me know and I’ll file it.
Comment 54 User image Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-07-29 11:09:56 PDT
Since the bulk of the keycodes were fixed, it's easier to track (and fix) the overlooked cases in a focused, separate bug.
Comment 55 User image Greg K. 2008-07-29 13:39:42 PDT
(In reply to comment #54)
> Since the bulk of the keycodes were fixed, it's easier to track (and fix) the
> overlooked cases in a focused, separate bug.

Filed as bug 448434.

Note You need to log in before you can comment on or make changes to this bug.