36062 - onkeypress not valuing 'which' properly (always 0)

Status: VERIFIED FIXED

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

Description

[Chris Casciano]

when interrogating the 'which' property of the event object generated by an 
onkeypress event I am always getting the value of 0. For comparison, using the 
onkeydown returns the proper value (the key's charcode).

Simplified test case already available at 
http://placenamehere.com/chris/temp/onkeypress.html

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Key events are no longer part of DOM Level 2.  However, this would probably be
nice, if which is what should hold the key code (I'm not sure of that).

Comment 2

[Asa Dotzler [:asa]]

setting to New

Comment 3

[joki (gone)]

This is simple and 4xp.  Nominating nsbeta3.  The fix should take five minutes.

Comment 4

[joki (gone)]

Okay, I have a fix.  It gets us very close to 4x behavior with some variations 
due to compliance with the early DOM 2 key specs.

Comment 5

[Kathleen :Brade]

joki--can you attach a patch?

Comment 6

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 7

[Wolfgang Schwarz]

So what code will event.which yield in Mozilla? 
At the moment, with onkeydown and onkeyup it gives the code of the pressed key 
irrespective of whether e.g. shift is pressed. This is how it is handled in IE, 
but not in Netscape 4. 
As long as there is no W3C specification I would prefer backward 
compatibility... 

Comment 8

[Kahli Burke]

Could I get an update as to when this fix will make it into a build?

Comment 9

[Nisheeth Ranjan]

Marking nsbeta3+

Comment 10

[Nisheeth Ranjan]

I get a 404 not found error when I try to access the above url.  Joki's fix has 
been checked in.  Can anybody else provide a test case, or better yet, use the 
latest nightly build and figure out whether this bug is fixed?  Regardless, we 
are not going to spend more time on this pre Netscape 6 ship.

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration, but do not clear 
the nsbeta3- nomination.

Comment 11

[Wolfgang Schwarz]

I tested it with build 2000081308 on win98 and it seems to work well now. I 
think status can be set to fixed.

Comment 12

[Chris Casciano]

sorry about that... I've made some major changes to my site and must have 
clobbered the temp directory... I'll reupload the test case to the URL specified 
this evening (EST)

Comment 13

[Chris Casciano]

I have re-uploaded the test case and have made the appropriate changes to the 
URL in this bug report.

After uploading the test case this evening I first hit the url with my copy of 
M16 confirming that I grabbed the right file out of my backups (cause I got 0 
all the time).

I have also done some preliminary testing with the most recent nightly (windows 
talkback build 2000081508) and it seems to be fixed. The script that spawned 
this bug is also now working and can be found at: 
http://www.placenamehere.com/chris/experiments/glyphs/coolGlyphs.html

Comment 14

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

Per comments, marking fixed.

Comment 15

[Loco]

Updating QA Contact.

Comment 16

[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 17

[Madhur Bhatia]

QA contact updated

Comment 18

[jerone]

verified on build 2001-08-10-trunk