Open
Bug 197497
Opened 22 years ago
Updated 2 years ago
edit fields don't handle control characters correctly
Categories
(Core :: Widget: Gtk, defect, P5)
Tracking
()
REOPENED
People
(Reporter: vincent-moz, Unassigned)
Details
(Keywords: helpwanted, Whiteboard: [gtk1-only?])
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030304 Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030304 Editable fields behave strangely when typing control characters that are sent due to keyboard reconfiguration with xmodmap. Reproducible: Always Steps to Reproduce: 1. Use xmodmap to bind a control character to a key combination. For instance: keycode 100 = Left 0x0001 Thus, typing Shift-LeftArrow is equivalent to Ctrl-A. 2. Put the cursor in an editable field, e.g. the Search field in the sidebar. 3. Type 'a', then Shift-LeftArrow, then 'b'. Actual Results: When typing 'a', the character 'a' appears as expected. When typing Shift-LeftArrow, a space appears. When typing 'b', the character 'b' appears just after the 'a' and the space remains after the 'b'. It seems that Mozilla behaves as if the Shift-LeftArrow were regarded as a character (so that at the end, the cursor is at position 3), but no character is really printed out. Expected Results: When typing Shift-LeftArrow (using the given xmodmap entry), Mozilla should put the cursor at the beginning of the line (like what Ctrl-A does).
![]() |
||
Comment 1•22 years ago
|
||
Which build is this? gtk? gtk2? with or without xft?
Reporter | ||
Comment 2•22 years ago
|
||
It is the build I got here: http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-powerpc-unknown-linux-gnu.tar.gz "About Mozilla" doesn't give additional information.
![]() |
||
Comment 3•21 years ago
|
||
Vincent, is this still an issue? If so, what does about:buildconfig say?
Reporter | ||
Comment 4•21 years ago
|
||
Still the same problem. about:buildconfig Build platform target powerpc-unknown-linux-gnu Build tools Compiler Version Compiler flags cc gcc version 3.3.2 (Debian) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe g++-3.2 gcc version 3.2.3 (Debian) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --prefix=/home/lefevre/mozilla --with-system-jpeg --with-system-zlib --with-system-png --with-system-mng --enable-calendar --enable-xft --enable-crypto --disable-debug --enable-optimize=-O2 --enable-reorder --enable-strip --enable-xterm-updates --enable-svg --enable-svg-renderer-libart
![]() |
||
Updated•21 years ago
|
Assignee: core.layout.form-controls → blizzard
Component: Layout: Form Controls → GFX: Gtk
QA Contact: desale → ian
Comment 5•19 years ago
|
||
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Reporter | ||
Comment 6•19 years ago
|
||
With Firefox 1.0.7 (Debian package 1.0.7-1), spaces are no longer printed out. But the bug is still there: Shift-LeftArrow now has no effect. My .gtkrc-2.0 contains: binding "text-entry" { bind "<ctrl>a" { "move-cursor" (paragraph-ends, -1, 0) } [...] } class "GtkEntry" binding "text-entry" class "GtkTextView" binding "text-entry" and Shift-LeftArrow produces a Ctrl-A character at the X server level: KeyPress event, serial 30, synthetic NO, window 0x2600001, root 0x40, subw 0x0, time 4088309, (124,74), root:(128,986), state 0x1, keycode 100 (keysym 0x1, (no name)), same_screen YES, XLookupString gives 1 bytes: (01) "" XmbLookupString gives 1 bytes: (01) "" XFilterEvent returns: False (keysym 0x1 is the code of Ctrl-A). This works well in xterm, aterm, rxvt and emacs for instance.
Reporter | ||
Updated•19 years ago
|
Hardware: Macintosh → All
![]() |
||
Comment 7•19 years ago
|
||
What about Trunk or 1.8 branch builds? The 1.7 branch is pretty old...
Reporter | ||
Comment 8•19 years ago
|
||
Same problem with Firefox 1.5 beta1.
![]() |
||
Comment 9•19 years ago
|
||
Confirming, then. roc, bryner, caillon, any idea what's up here? This sounds like we're not picking up the OS keybindings correctly...
Status: UNCONFIRMED → NEW
Component: GFX: Gtk → Widget: Gtk
Ever confirmed: true
Flags: blocking1.9a1?
QA Contact: ian → gtk
Updated•18 years ago
|
Flags: blocking1.9a1? → blocking1.9-
![]() |
||
Comment 10•18 years ago
|
||
This needs a real owner. roc, bryner, any ideas on this, or at least on who can look into this?
Assignee: blizzard → nobody
Keywords: helpwanted
I'm afraid not. I could look into it in theory, but it's not high enough priority for me.
Comment 12•18 years ago
|
||
Does this bug occur in a recent trunk build? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Whiteboard: [gtk1-only?]
Comment 13•5 years ago
|
||
Priority: -- → P5
Updated•2 years ago
|
Severity: minor → S4
Updated•2 years ago
|
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INACTIVE
Reporter | ||
Comment 14•2 years ago
|
||
This bug still occurs with Firefox 108.0.2, though I now use XKB instead of xmodmap to rebind keys. For instance, I have
key <LEFT> {
type = "CUSTLEVELTHREE",
symbols[Group1] = [ Left, 0x1000001 ]
};
to generate a Ctrl-A with ISO_Level3_Shift + left key. Instead of doing what Ctrl-A normally does (via the GTK bindings), Firefox inserts a Ctrl-A character (which appears as a square with 0001 on 2 lines, as usually for codepoints that do not have a glyph in the font).
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•