Open Bug 197497 Opened 17 years ago Updated 10 months ago

edit fields don't handle control characters correctly


(Core :: Widget: Gtk, defect, P5, minor)





(Reporter: vincent-moz, Unassigned)


(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).
Which build is this?  gtk? gtk2? with or without xft?
It is the build I got here:

"About Mozilla" doesn't give additional information.
Vincent, is this still an issue?  If so, what does about:buildconfig say?
Still the same problem.


Build platform

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
Assignee: core.layout.form-controls → blizzard
Component: Layout: Form Controls → GFX: Gtk
QA Contact: desale → ian
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:
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

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.
Hardware: Macintosh → All
What about Trunk or 1.8 branch builds?   The 1.7 branch is pretty old...
Same problem with Firefox 1.5 beta1.
Confirming, then.  roc, bryner, caillon, any idea what's up here?  This sounds
like we're not picking up the OS keybindings correctly...
Component: GFX: Gtk → Widget: Gtk
Ever confirmed: true
Flags: blocking1.9a1?
QA Contact: ian → gtk
Flags: blocking1.9a1? → blocking1.9-
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.
Does this bug occur in a recent trunk build?
Whiteboard: [gtk1-only?]
You need to log in before you can comment on or make changes to this bug.