197497 - edit fields don't handle control characters correctly

Status: REOPENED

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

Description

[Vincent Lefevre]

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

[Boris Zbarsky [:bzbarsky]]

Which build is this?  gtk? gtk2? with or without xft?

Comment 2

[Vincent Lefevre]

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

[Boris Zbarsky [:bzbarsky]]

Vincent, is this still an issue?  If so, what does about:buildconfig say?

Comment 4

[Vincent Lefevre]

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

Comment 5

[Gervase Markham [:gerv]]

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/

Comment 6

[Vincent Lefevre]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

What about Trunk or 1.8 branch builds?   The 1.7 branch is pretty old...

Comment 8

[Vincent Lefevre]

Same problem with Firefox 1.5 beta1.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Confirming, then.  roc, bryner, caillon, any idea what's up here?  This sounds
like we're not picking up the OS keybindings correctly...

Comment 10

[Boris Zbarsky [:bzbarsky]]

This needs a real owner.

roc, bryner, any ideas on this, or at least on who can look into this?

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm afraid not. I could look into it in theory, but it's not high enough priority for me.

Comment 12

[Mats Palmgren (inactive)]

Does this bug occur in a recent trunk build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 13

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1552613

Comment 14

[Vincent Lefevre]

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).