Bug 246097 - window.event.keyCode may return wrong value
Summary: window.event.keyCode may return wrong value
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml ecma (other bugs)
Version First Reported In: 4.4.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Konqueror Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-29 00:39 UTC by duke_the_killer
Modified: 2024-05-06 20:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description duke_the_killer 2010-07-29 00:39:54 UTC
Version:           4.4.0 (using KDE 4.4.0) 
OS:                MS Windows

Found nothing in the changelogs between 4.4.0 and 4.4.5
Values returned in document.onkeypress and document.onkeydown are the same

document.onkeydown should be a "hardware key", the key pressed on my keyboard
document.onkeypress should be a "software key", the character that will appear

Reproducible: Always

Steps to Reproduce:
Test page: http://xirc.chez.com/onkeypress.html
Press:

Shift + 1
Shift + Alt + 1
Ctrl + Alt + 1
Ctrl + Shift + 1
Ctrl + Shift + Alt + 1

Actual Results:  
First 3 tests, onkeydown returns keyCode 33 33 177
Last 2 tests, onkeypress returns keyCode 49 49

Expected Results:  
First 3 tests should return 49 (value for "1" key)
Last 2 tests should return 33 (value for "!" key)
Comment 1 Maksim Orlovich 2010-07-29 15:55:01 UTC
Hi... Thanks for the very nice bug report; unfortunately your link seems to be broken?
Comment 2 duke_the_killer 2010-07-29 16:41:16 UTC
Silly me manually typing it
http://xirc.chez.com/onkeydown.html

Interesting links

Keys IE use for onkeypress http://msdn.microsoft.com/en-us/library/ms536939(VS.85).aspx

Keys IE use for onkeydown http://msdn.microsoft.com/en-us/library/ms536938(VS.85).aspx

I just saw W3C changed their wording when it comes to onkeypress between drafts, http://www.w3.org/TR/DOM-Level-3-Events/#events-keyboardevents
"Whether a keypress contributes or not to the generation of a text event is implementation dependent."


If we want "onkeypress = inserts character" then last 4 tests should not trigger it (they output nothing)
I could also add Alt + 1, Ctrl + 1, Alt + Shift + 1 to the test list

Opera and Gecko/Firefox currently behave like Konqueror
Trident/IE and Webkit/Chrome-Safari don't
Comment 3 Andrew Crouthamel 2018-11-05 03:07:57 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Andrew Crouthamel 2018-11-16 05:37:04 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version?

Thank you for helping us make KDE software even better for everyone!
Comment 5 Christoph Cullmann 2024-05-06 20:51:16 UTC
Dear user,

KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6.

Please migrate to use a QWebEngine based HTML component.

We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes.

For security issues, please see:

https://kde.org/info/security/

Sorry that we did not fix this issue during the life-time of KHTML.

Greetings
Christoph Cullmann