48951 - Need to use VK_ keyCode constants in .js files

Status: RESOLVED WONTFIX

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

Description

[Aaron Leventhal]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
BuildID:    200073008

Right now, people are using hard coded constants for keyCode.
For example, if (keyCode==13) {dosomething();}
That's not good! Should be able to say if (keyCode==VK_ENTER) ...

Reproducible: Always
Steps to Reproduce:
1. Try to use any VK_ or DOM_VK constant, it doesn't work.
2.
3.

Actual Results:  		-					

Expected Results:  							-

							-

Comment 1

[Akkana Peck]

I'll take this one -- it's related to some other work I'm doing.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Reassigning to akkana.

Comment 3

[Akkana Peck]

It turns out that most of these are already available, in MouseKeyEvent.idl.  I
have a fix in my tree (awaiting review and XP testing of a bunch of other
associated changes) which makes the NS_VK_* symbols in nsGUIEvent.h dependant on
the dom versions of the same symbols (which in turn are generated from
MouseKeyEvent.idl), so we'll only have one master copy of the keycode list.

Comment 4

[Akkana Peck]

The symbols come from MouseKeyEvent.idl.  The fix I mentioned to reconcile the
symbols in widget has been checked in.  In theory, you should be able to use the
VK_ symbols from JS.  In practice, I haven't had a chance to test this.  Someone
please try it and see if it works!

Comment 5

[Aaron Leventhal]

Akkana, I've just tested this with a cvs build from after your last report. I 
see that DOM_VK_blah are all defined in MouseKeyEvent.idl, but I get a 
Javascript 'symbol undefined' error when I try to use one of them. Is there 
some statement I need in the javascript to make those .idl definitions 
available?

Comment 6

[Axel Hecht]

The fix to dom/public/idl/events/MouseKeyEvent.idl won't go into the tree,
as the rest of dom/public/idl.
The results of idlc need to be generated and checked in, to get this into the
build.
Are those names defined in DOM3? I just saw links to the first public
working draft on w3.org, but those aren't public yet. (access denied).
Adding jst and vidur for insight in dom standards and building wisdom

Axel

Comment 7

[rubydoo123]

moving to future

Comment 8

[Loco]

Updating QA Contact.

Comment 9

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 10

[Madhur Bhatia]

QA contact updated

Comment 11

[:aceman]

Akkana, are you still working on this?
Also, it seems .keyCode is deprecated.

Comment 12

[Akkana Peck]

No, sorry, I don't even have a copy of the codebase any more.

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Is this still valid?

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ideally (if we need to keep using .keyCode in our tree), yes. However, in most cases, we should use .key and as far as I know, new frontend code uses .key. Therefore, I think that we should switch from .keyCode to .key rather than updating .keyCode comparisons.

Anyway, this kind of bug is not useful because most developers update such code when they touch without blocking this bug. Let's close this.