WARNING: GetCharCode used for wrong key event; should use onkeypress., file ../../../../../mozilla/content/events/src/nsDOMKeyboardEvent.cpp, line 108

RESOLVED FIXED

Status

()

Core
Widget: Gtk
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: Biesinger, Assigned: timeless)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

linux gtk2 seamonkey trunk, checkout finish: So Sep 18 22:29:45 CEST 2005

Typing in the location bar shows a lot of:
WARNING: GetCharCode used for wrong key event; should use onkeypress., file
../../../../../mozilla/content/events/src/nsDOMKeyboardEvent.cpp, line 108
(cc'ing dbaron since this is also seen in the layout debugger. but might this be
an issue in the <textbox> xbl binding?)

Comment 2

12 years ago
I think the gtk2 native keybinding code calls GetCharCode on all key events.
-> widget:gtk2 then, I guess.
Assignee: guifeatures → blizzard
Component: XP Apps: GUI Features → Widget: Gtk
Product: Mozilla Application Suite → Core
QA Contact: gtk
Version: unspecified → Trunk
It seems the problem is that in nsXBLWindowKeyHandler::WalkHandlers[1] we
unconditinally call nsDOMKeyboardEvent::GetCharCode if we have a
nsINativeKeyBindings impl (which only GTK2 has, AFAIK).

1:
<http://lxr.mozilla.org/seamonkey/source/content/xbl/src/nsXBLWindowKeyHandler.cpp#198>
See also http://lxr.mozilla.org/mozilla/source/layout/forms/nsTextControlFrame.cpp#393 . What's the right solution here? Should these two places only call GetCharCode in certain cases?

Comment 6

12 years ago
(In reply to comment #4)
>http://lxr.mozilla.org/seamonkey/source/content/xbl/src/nsXBLWindowKeyHandler.cpp#198
This should probably check for aEventType == nsXBLAtoms::keypress first.
I'm not sure what the best fix for nsTextControlFrame is offhand.
DOMEventToNativeKeyEvent is only used in nsTextControlFrame.cpp (in nsTextInputListener::KeyDown, ::KeyPress, ::KeyUp), so the method signature for DOMEventToNativeKeyEvent could easily be changed to take aEventType as well, for example.
Ginn Chen, I bet this is the bug you want to fix instead of making the change you made in bug 295228.
(Assignee)

Comment 9

12 years ago
Created attachment 214505 [details] [diff] [review]
draft for xbl
Attachment #214505 - Flags: superreview?(bzbarsky)
Attachment #214505 - Flags: review?(bzbarsky)
Attachment #214505 - Flags: superreview?(bzbarsky)
Attachment #214505 - Flags: superreview+
Attachment #214505 - Flags: review?(bzbarsky)
Attachment #214505 - Flags: review+
(Assignee)

Comment 10

12 years ago
Comment on attachment 214505 [details] [diff] [review]
draft for xbl

mozilla/content/xbl/src/nsXBLWindowKeyHandler.cpp 	1.30
Attachment #214505 - Attachment is obsolete: true
(Assignee)

Updated

12 years ago
Assignee: blizzard → timeless
(Assignee)

Updated

12 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Blocks: 330133
This caused bug 330133...

Comment 12

12 years ago
This is only partly fixed.  The code in DOMEventToNativeKeyEvent() (see comment 5, comment 7) still spews warnings to the console.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 220215 [details] [diff] [review]
Brutal hack

This isn't the cleanest way to do this, but it works.
Attachment #220215 - Flags: superreview?(dbaron)
Attachment #220215 - Flags: review?(dbaron)
Attachment #220215 - Flags: superreview?(dbaron)
Attachment #220215 - Flags: superreview+
Attachment #220215 - Flags: review?(dbaron)
Attachment #220215 - Flags: review+
Checked in.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.