Closed Bug 26264 Opened 21 years ago Closed 17 years ago

gtk: need to generate KeyPress for control and shift


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






(Reporter: akkzilla, Assigned: akkzilla)


(Keywords: helpwanted, Whiteboard: [keybnd])


(2 files)

Split off from bug 6649: the linux event handler generates KeyPress events for
the alt key, but not for control and shift.  It should treat these all equally.
Target Milestone: M20
moving to future milestone
Assignee: akkana → beppe
moving back to previous owner
Assignee: beppe → akkana
Target Milestone: M20 → Future
adding help wanted keyword
Keywords: helpwanted
Mass update:  changing qacontact to
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Whiteboard: [keybnd]
QA contact updated
QA Contact: gerardok → madhur
Added test case, and just noticed ticket was for Linux bug.  I am using a Winnt 
5.0(win2000) workstation w/ netscape 6.1 prerelease 1.  I will attempt to add 
bug report for Winnt version
QA Contact: madhur → rakeshmishra
QA Contact: rakeshmishra → trix
Could someone describe exactly what behavior should be seen for this bug?
I compared the behavior of the Windows vs. Linux versions of Moz with the
attached test case, and they seem identical, with the following exception:
The Windows version does not produce keypress events for Caps Lock, Shift,
Ctrl, Alt or Print Scrn, whereas the Linux version produces keypress events
for all keys except Shift and Ctrl.
This is a linux-specific bug.  There is probably a Windows-specific bug that
deals with other (similar sounding) issues (comment 11 may contain some/all of
the issues for Windows but that should NOT be covered in this bug).  There's
also a Mac version of this type of bug where lots of modifier key events are not
generated at all--again, these issues do not belong in a GTK-specific bug.

This bug is accurately summarized:  GTK needs to generate keypress events when
the control key is pressed and when the shift key is pressed.
This patch works for me.  However, I'm very concerned about the correctness
of this because the code I'm removing was checked in by tague to fix bug 6896
and because I'm unfamiliar with how keycodes ultimately get used by various
Could someone please comment on why this change would or would not cause a 
Comment on attachment 129700 [details] [diff] [review]
Patch to not suppress Shift and Control key events

This patch looks fine to me.  I'd make sure you test things like:
 * pressing shift-number, letter combinations when typing (make sure you don't
get extra characters)
 * access menus via keyboard
 * keyboard shortcuts (control-s to save, control-shift-G to find previous,
 * shift-click and control-click combinations (test in both browser and mail
compose/page composer)

I don't have a linux setup right now so I can't help with the above testing. 
If all that testing works as it should, r=brade
Comment on attachment 129700 [details] [diff] [review]
Patch to not suppress Shift and Control key events

Brade, I tested everything in your list without any weird behavior, and I
haven't noticed anything odd through normal usage (this has been in my build
for the past two weeks).
Attachment #129700 - Flags: review?(brade)
Attachment #129700 - Flags: review?(brade) → review+
Please mark this as WONTFIX. 
KeyPress events are not generated for Alt, Shift and Ctrl by design. This is a 
non-standard event (not covered by the DOM Events model) and we're free to 
handle it as we please. In this case, IE compatibility becomes our main goal. 
IE generates KeyPress only for: 
Letters: A - Z (uppercase and lowercase)  
Numerals: 0 - 9  
Symbols: ! @ # $ % ^ & * ( ) _ - + = < [ ] { } , . / ? \ | ' ` " ~  
The intention is to make KeyPress behave more like DOM3's TextEvent.. 
On the other hand, KeyUp and KeyDown MUST be generated for Alt/Shift/Ctrl. 
Closed: 17 years ago
Resolution: --- → WONTFIX
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.