New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 351230 link

Starred by 49 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Blocked on:
issue 354495



Sign in to add a comment

Ignores Compose key on Linux+aura with xim input module

Reported by ande...@mit.edu, Mar 11 2014

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1870.2 Safari/537.36

Steps to reproduce the problem:
1. Run im-config and select the xim input module.  Log out and log in for the change to take effect.  (I think this is equivalent to setting the environment variables XMODIFIERS=@im=none GTK_IM_MODULE=xim QT4_IM_MODULE=xim CLUTTER_IM_MODULE=xim.)
2. Configure the keyboard layout to enable a Compose key (https://help.ubuntu.com/community/ComposeKey).
3. Press Compose ' e.

What is the expected behavior?
Chrome reads é.

What went wrong?
Chrome ignores the Compose key and reads 'e.

Did this work before? Yes Chrome 34 (pre-aura)

Chrome version: 35.0.1870.2  Channel: dev
OS Version: Ubuntu 14.04
Flash Version: Shockwave Flash 12.0 r0
 
Labels: Proj-DesktopAura

Comment 2 by e...@chromium.org, Mar 11 2014

Cc: kenjibaheux@chromium.org msw@chromium.org yukishiino@chromium.org
Adding input-y people.

Comment 3 by msw@chromium.org, Mar 11 2014

Labels: Cr-UI-Input-Text-IME Cr-UI-Input-Text Cr-UI-Internationalization

Comment 4 by e...@chromium.org, Mar 11 2014

Labels: -Pri-2 Pri-1

Comment 5 by e...@chromium.org, Mar 11 2014

 Issue 351305  has been merged into this issue.
Labels: -Pri-1 Pri-2
The merged 351305 is more concerning than the compose key issue. Was anyone able to repro 351305?

Comment 7 by e...@chromium.org, Mar 11 2014

I had assumed the two were equivalent. Should they be unduped?

Comment 8 by r...@cybikbase.com, Mar 11 2014

The fr_ca keyboard has one key for é; that letter is not the result of a composition in fr_ca's case.

Comment 9 by e...@chromium.org, Mar 11 2014

My appologies. Unduping.

Comment 10 by k...@nguyen.vg, Mar 12 2014

If that helps, I also remarked the following behaviour:
1) launch chrome, give the focus to the url bar. Compose-'-e gives 'e
2) go to a terminal, type  setxkbmap -option compose:ralt
3) go back to chrome url bar now: compose-'-e gives é
4) compose stops working when the focus changes to something else (in particular the web page displayed and back to the url bar).

this "trick" never works on dialogs in the web page rendered in Chrome (i.e. compose never works there).

Status: Available
P2 but lower than  issue 351305 
Owner: pkotw...@chromium.org
Status: Started
As an update, adding gtk_im_multicontext_set_context_id(GTK_IM_MULTICONTEXT(gtk_multicontext_), "gtk-im-context-simple");
to X11InputMethodContextImplGtk2 fixes the bug

Now I need to investigate what the proper fix is
It looks like gdk_x11_window_foreign_new_for_display() is causing problems. I will upload the test app that I wrote shortly
Cc: pkotw...@chromium.org
Owner: ----
Status: Available
I have attached a minimal GTK/X11 app which correctly accepts the compose key. I am putting the bug back into the queue because I do not believe that I can fix this bug by Friday.
compose_key_minimal.c
4.0 KB Download
 Issue 351689  has been merged into this issue.
It seems GTK_IM_MODULE=gtk-im-context-simple can be used as a workaround.

Comment 17 by r...@cybikbase.com, Mar 27 2014

Launching Chrome by doing 

GTK_IM_MODULE=gtk-im-context-simple google-chrome-unstable

sadly does not give me the acute e or the "1/2" character, Shiino-san :(

Comment 18 by ande...@mit.edu, Mar 28 2014

GTK_IM_MODULE=gtk-im-context-simple lets the Compose key work with GTK’s built-in compose sequences, but not any user-configured sequences in ~/.XCompose (which is why I’m using xim in the first place).
Owner: pkotw...@chromium.org
Status: Assigned
I found the bug!

The reason for this bug is that X11 sends the compose keystroke to the XDisplay that was passed into XOpenIM().

The X11 display passed into XOpenIM()
- is the X display for gdk_display_get_default()
- is not gfx::GetXDisplay()

gdk_x11_lookup_xdisplay() fails

So we never get the "compose key stroke" because we are not listening for key events from the display that the "compose key stroke" is sent to.

I have attached a minimal GTK/X11 which demonstrates the bug
compose_key_demo_bug.c
3.7 KB Download
Blockedon: chromium:354495
The root cause of this bug seems very similar to the root cause of  Issue 354495 . Blocking on that issue getting fixed
Labels: M-35

Comment 23 by kareng@google.com, Apr 7 2014

Labels: -M-35 MovedFrom-35 M-36
Moving all non essential bugs to the next Milestone.
Mergedinto: 354495
Status: Duplicate
This bug was fixed as part of https://codereview.chromium.org/224723008
Marking as duplicate of 354495

Comment 25 by ande...@mit.edu, Apr 16 2014

I can still reproduce this bug on
  36.0.1941.0 (Official Build 263744) dev aura
  36.0.1943.0 (Developer Build 264167) custom

If  bug 354495  was fixed by r262352, then this is not a duplicate.  Can you please unmerge it?
Mergedinto:
Status: Assigned
Owner: yukishiino@chromium.org
andersk@mit.edu, you are right, https://codereview.chromium.org/224723008 is not sufficient to fix the bug

I have a super hacky horrendous CL which fixes the bug at https://codereview.chromium.org/236313018/
yukishiino@, I am assigning this bug to you. You have a lot more context on IME and it will be significantly easier for you to fix the bug properly than for me to do so
There are three bugs:
- gtk_im_context_set_client_window() should only be called when the client window changes. Internally, GTK causes XDestroyIC(),XCreateIC() are called for each call to gtk_im_context_set_client_window()
- We do not propagate the keycode of zero (which indicates that an input has composed input) to X11InputMethodContextImplGtk2::DispatchKeyEvent() because the keycode maps to VKEY_UNKNOWN
- GTK logs a warning "gdk_window_set_user_time called on non-toplevel" with my CL applied. I think that it is probably ok to ignore the warning.
Status: Started

Comment 29 by e...@chromium.org, Apr 18 2014

I'm unsure about ignoring gdk_window_set_user_time() at the glib level. Whatever is going wrong in other IME bugs (example:  issue 360388 ,  issue 349163 ), that output line is spewing for people.
Project Member

Comment 31 by bugdroid1@chromium.org, Apr 28 2014

Labels: merge-merged-git-svn
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/73749e6aec0682f0e5534c98691421318d7285c7

commit 73749e6aec0682f0e5534c98691421318d7285c7
Author: piman@chromium.org <piman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Mon Apr 28 20:49:26 2014 +0000

linux-aura: Supports Compose key with XIM.

Supports Compose key with XIM and makes .XCompose settings effective with Linux Aura build.

BUG= 351230 , 360388 
TEST=Done manually.  Tested with GTK_IM_MODULE=xim XMODIFIERS=@im=none and ~/.XCompose with custom contents.
R=erg@chromium.org, sadrul@chromium.org

Review URL: https://codereview.chromium.org/243143002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@266651 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 32 by bugdroid1@chromium.org, Apr 29 2014

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/483459e9a5e77f2564b75fff27126310c5c2e1b5

commit 483459e9a5e77f2564b75fff27126310c5c2e1b5
Author: erg@chromium.org <erg@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Apr 29 21:58:52 2014 +0000

Merge 266651 "linux-aura: Supports Compose key with XIM."

> linux-aura: Supports Compose key with XIM.
> 
> Supports Compose key with XIM and makes .XCompose settings effective with Linux Aura build.
> 
> BUG= 351230 , 360388 , 349163 
> TEST=Done manually.  Tested with GTK_IM_MODULE=xim XMODIFIERS=@im=none and ~/.XCompose with custom contents.
> R=erg@chromium.org, sadrul@chromium.org
> 
> Review URL: https://codereview.chromium.org/243143002

TBR=piman@chromium.org,yukishiino@chromium.org

Review URL: https://codereview.chromium.org/260573002

git-svn-id: svn://svn.chromium.org/chrome/branches/1916/src@266967 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 33 by bugdroid1@chromium.org, Apr 29 2014

Labels: merge-merged-1916
------------------------------------------------------------------
r266967 | erg@chromium.org | 2014-04-29T21:58:52.347861Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/chrome/browser/ui/libgtk2ui/x11_input_method_context_impl_gtk2.cc?r1=266967&r2=266966&pathrev=266967
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/chrome/browser/ui/libgtk2ui/x11_input_method_context_impl_gtk2.h?r1=266967&r2=266966&pathrev=266967
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/events/event_constants.h?r1=266967&r2=266966&pathrev=266967
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/events/x/events_x.cc?r1=266967&r2=266966&pathrev=266967
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/base/ime/input_method_auralinux.cc?r1=266967&r2=266966&pathrev=266967
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/aura/window_targeter.cc?r1=266967&r2=266966&pathrev=266967

Merge 266651 "linux-aura: Supports Compose key with XIM."

> linux-aura: Supports Compose key with XIM.
> 
> Supports Compose key with XIM and makes .XCompose settings effective with Linux Aura build.
> 
> BUG= 351230 , 360388 , 349163 
> TEST=Done manually.  Tested with GTK_IM_MODULE=xim XMODIFIERS=@im=none and ~/.XCompose with custom contents.
> R=erg@chromium.org, sadrul@chromium.org
> 
> Review URL: https://codereview.chromium.org/243143002

TBR=piman@chromium.org,yukishiino@chromium.org

Review URL: https://codereview.chromium.org/260573002
-----------------------------------------------------------------
Project Member

Comment 34 by bugdroid1@chromium.org, Apr 29 2014

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/40d952e06441d909c2305745b883c68dc996d04c

commit 40d952e06441d909c2305745b883c68dc996d04c
Author: erg@chromium.org <erg@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Apr 29 22:20:21 2014 +0000

Revert 266967 "Merge 266651 "linux-aura: Supports Compose key wi..."

Compile failure:
../../ui/events/x/events_x.cc: In function ‘int {anonymous}::GetEventFlagsFromXKeyEvent(XEvent*)’:
../../ui/events/x/events_x.cc:172:51: error: ‘IsKeypadKey’ was not declared in this scope

> Merge 266651 "linux-aura: Supports Compose key with XIM."
> 
> > linux-aura: Supports Compose key with XIM.
> > 
> > Supports Compose key with XIM and makes .XCompose settings effective with Linux Aura build.
> > 
> > BUG= 351230 , 360388 , 349163 
> > TEST=Done manually.  Tested with GTK_IM_MODULE=xim XMODIFIERS=@im=none and ~/.XCompose with custom contents.
> > R=erg@chromium.org, sadrul@chromium.org
> > 
> > Review URL: https://codereview.chromium.org/243143002
> 
> TBR=piman@chromium.org,yukishiino@chromium.org
> 
> Review URL: https://codereview.chromium.org/260573002

TBR=erg@chromium.org

Review URL: https://codereview.chromium.org/253183002

git-svn-id: svn://svn.chromium.org/chrome/branches/1916/src@266978 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 35 by bugdroid1@chromium.org, Apr 29 2014

------------------------------------------------------------------
r266978 | erg@chromium.org | 2014-04-29T22:20:21.408175Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/chrome/browser/ui/libgtk2ui/x11_input_method_context_impl_gtk2.cc?r1=266978&r2=266977&pathrev=266978
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/chrome/browser/ui/libgtk2ui/x11_input_method_context_impl_gtk2.h?r1=266978&r2=266977&pathrev=266978
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/events/event_constants.h?r1=266978&r2=266977&pathrev=266978
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/events/x/events_x.cc?r1=266978&r2=266977&pathrev=266978
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/base/ime/input_method_auralinux.cc?r1=266978&r2=266977&pathrev=266978
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/aura/window_targeter.cc?r1=266978&r2=266977&pathrev=266978

Revert 266967 "Merge 266651 "linux-aura: Supports Compose key wi..."

Compile failure:
../../ui/events/x/events_x.cc: In function ‘int {anonymous}::GetEventFlagsFromXKeyEvent(XEvent*)’:
../../ui/events/x/events_x.cc:172:51: error: ‘IsKeypadKey’ was not declared in this scope

> Merge 266651 "linux-aura: Supports Compose key with XIM."
> 
> > linux-aura: Supports Compose key with XIM.
> > 
> > Supports Compose key with XIM and makes .XCompose settings effective with Linux Aura build.
> > 
> > BUG= 351230 , 360388 , 349163 
> > TEST=Done manually.  Tested with GTK_IM_MODULE=xim XMODIFIERS=@im=none and ~/.XCompose with custom contents.
> > R=erg@chromium.org, sadrul@chromium.org
> > 
> > Review URL: https://codereview.chromium.org/243143002
> 
> TBR=piman@chromium.org,yukishiino@chromium.org
> 
> Review URL: https://codereview.chromium.org/260573002

TBR=erg@chromium.org

Review URL: https://codereview.chromium.org/253183002
-----------------------------------------------------------------
Project Member

Comment 36 by bugdroid1@chromium.org, Apr 29 2014

------------------------------------------------------------------
r266994 | erg@chromium.org | 2014-04-29T23:39:31.069407Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/chrome/browser/ui/libgtk2ui/x11_input_method_context_impl_gtk2.cc?r1=266994&r2=266993&pathrev=266994
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/chrome/browser/ui/libgtk2ui/x11_input_method_context_impl_gtk2.h?r1=266994&r2=266993&pathrev=266994
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/events/event_constants.h?r1=266994&r2=266993&pathrev=266994
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/events/x/events_x.cc?r1=266994&r2=266993&pathrev=266994
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/base/ime/input_method_auralinux.cc?r1=266994&r2=266993&pathrev=266994
   M http://src.chromium.org/viewvc/chrome/branches/1916/src/ui/aura/window_targeter.cc?r1=266994&r2=266993&pathrev=266994

Merge 266651 "linux-aura: Supports Compose key with XIM."

Hopefully this will go better with the r264257 dependency merged...

> linux-aura: Supports Compose key with XIM.
> 
> Supports Compose key with XIM and makes .XCompose settings effective with Linux Aura build.
> 
> BUG= 351230 , 360388 
> TEST=Done manually.  Tested with GTK_IM_MODULE=xim XMODIFIERS=@im=none and ~/.XCompose with custom contents.
> R=erg@chromium.org, sadrul@chromium.org
> 
> Review URL: https://codereview.chromium.org/243143002

TBR=piman@chromium.org

Review URL: https://codereview.chromium.org/253233002
-----------------------------------------------------------------
Project Member

Comment 37 by bugdroid1@chromium.org, Apr 29 2014

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/310f2cb709c682216749e2e05935c5f29a04e870

commit 310f2cb709c682216749e2e05935c5f29a04e870
Author: erg@chromium.org <erg@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Apr 29 23:39:31 2014 +0000

Merge 266651 "linux-aura: Supports Compose key with XIM."

Hopefully this will go better with the r264257 dependency merged...

> linux-aura: Supports Compose key with XIM.
> 
> Supports Compose key with XIM and makes .XCompose settings effective with Linux Aura build.
> 
> BUG= 351230 , 360388 
> TEST=Done manually.  Tested with GTK_IM_MODULE=xim XMODIFIERS=@im=none and ~/.XCompose with custom contents.
> R=erg@chromium.org, sadrul@chromium.org
> 
> Review URL: https://codereview.chromium.org/243143002

TBR=piman@chromium.org

Review URL: https://codereview.chromium.org/253233002

git-svn-id: svn://svn.chromium.org/chrome/branches/1916/src@266994 0039d316-1c4b-4281-b951-d872f2087c98


Mergedinto: 360388
Status: Duplicate

Comment 39 by ande...@mit.edu, May 1 2014

Can we please stop merging this into bugs that are not related to the Compose key?  This is still broken for me in today’s builds.

35.0.1916.86 (Official Build 266998) beta
36.0.1964.2 (Official Build 266749) dev

When testing with a freshly created account, I can see that things have gotten a little better.  The first time I open a Chrome window, the Compose key works with my custom sequences.  If I switch to a different window and back, then the behavior depends on which part of the Chrome window I clicked on to refocus it.  If I clicked on a text box in a web page, then Compose still works.  If I clicked on the URL bar, then Compose only works with the builtin GTK sequences, as if GTK_IM_MODULE=xim was completely forgotten.  Clicking on the web page again restores the working behavior.

When testing on my own account (not freshly created), Compose sequences are not working at all.  Neither the final composed character nor the individual characters in the input sequence are being read.  Exception: if I focus Chrome by clicking on the URL bar, then the builtin GTK sequences start working temporarily as above.

I have not yet figured out what makes my account different from a freshly created one, but hopefully the first part at least provides reproducible evidence that something is still wrong.
Mergedinto:
Status: Assigned
Thanks for the detailed report.  The issue seems coming from text input focus management rather than it's a Compose key issue.  I'll keep this issue open til the issue get fixed.

Comment 41 by Deleted ...@, May 26 2014

Something interesting I'm seeing: it's aware of the compose sequences, it's just not producing the final composed character.

If I press <Compose> ' e x (to produce éf), I get x.
If I press <Compose> - - - f (to produce —x), I get x.

Labels: -M-36 MovedFrom-36
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
I don't know if this is related. But i can't also enter the ` character at all anymore (had to copy & paste it here). As a developer this is kind of annoying as this key is used all the time with markdown.

I'm on Ubuntu 14.04 with Chrome Version 35.0.1916.114.

Sidenote: It's really sad to see so many frustrating bugs in Chrome. It's also messing up my passswords completely. Those are really severe issues which make the browser almost unusable. I wonder, why those things get messed up that worked so well before. 

Comment 44 by ole...@olegon.ru, Jun 14 2014

35.0.1916.153 affected... May be somebody can find workaround in chrome://flags/?

Comment 45 by ande...@mit.edu, Jul 2 2014

Original reporter here.  I observed that changing my input method from XIM to UIM allows me to work around this bug and keep my custom ~/.XCompose sequences.  It breaks Emacs, however (http://bugs.debian.org/753534).

With XIM, I can still reproduce the original problem (36.0.1985.103 now, for those who like watching numbers go up).
I cannot reproduce the issue with 36.0.1985.103, which should include the fix http://crrev.com/243143002 .  I can type my custom ~/.XCompose sequences with the following environment.

GTK_IM_MODULE=xim
XMODIFIERS=@im=none
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_ALL=en_US.UTF-8

Comment 47 by ande...@mit.edu, Jul 3 2014

I’m trying to figure out what’s different between my account and a freshly created account that could possibly be causing this.  I went so far as to write a script that runs Chrome in as empty of an environment as I could think of:

set -eux
tmphome=$(mktemp -d tmphome.XXXXXX)
cp ~/.XCompose "$tmphome"
cd "$tmphome"
env -i HOME="$tmphome" DISPLAY="$DISPLAY" LANG=en_US.UTF-8 \
    XMODIFIERS=@im=none GTK_IM_MODULE=xim \
    Xephyr :50 -resizeable -keybd ephyr,,,xkbmodel=evdev,xkblayout=us,xkboptions=compose:ralt &
sleep 1
env -i HOME="$tmphome" DISPLAY=:50 LANG=en_US.UTF-8 \
    XMODIFIERS=@im=none GTK_IM_MODULE=xim \
    google-chrome-beta

But when I run that script under my own account, I can reproduce the bug (no output from Compose sequences), and when I run it under a freshly created account, I can’t.  Gwaaah!  What could I be missing?
In reply to #47
> What could I be missing?

Are there any extensions enabled only in your main profile?
@#47: What about X session resources? "xrdb -query"

Comment 50 by ande...@mit.edu, Jul 3 2014

There are no extensions (Chrome created a fresh new profile inside its empty $HOME), and no X session resources inside the Xephyr.
Same problem. Arch Linux (updated), Chromium 35.0.1916.153 (274914). No accents work in a logged session. Incognito windows works as expected. The moment I log on to google account on the incognito window, the accents stop working. 
Same problem here on Arch with Chromium 35.0.1916.153 (274914) as well. My accents from ~/.XCompose (e.g. Multi_key> <a> <u> : "ä" U00E4 #SMALL A WITH DIAERESIS) do not work at all, and in Incognito mode I get wrong umlauts (e.g., 'ŭ' instead of 'ü'). I'm using GTK_IM_MODULE=xim. Any suggestions?

Comment 53 by Deleted ...@, Jul 20 2014

The same bug on archlinux x64 / xfce4

chromium was builded from source (package chromium-dev), version 38.0.2096.0 (283571) (64-bit)
XCompose is not work
but it work in google-chrome-stable (32.0.1700.107) and other text editors

Comment 54 by Deleted ...@, Aug 20 2014

Fixed for me since 36

Comment 55 by ande...@mit.edu, Aug 20 2014

I’m glad for you, but it’s still broken for me in 37.0.2062.76 (Official Build 289124) beta.
Using Chrome 36 here. Typing "Compose, ' (single-quote), E (upper-case E, i.e. Shift+E)" yields nothing in Chrome. It works correctly in other applications.
Just as a heads up.  Another fix that might be related to this issue has been landed for  Issue 395019 .
If you are still seeing this issue, can you try Chrome 38.0.2125.8 or later?  Now Chrome dev channel release for Linux contains that fix.
With 38.0.2125.8, compose works again for me :). Thanks!

What’s still broken is “layer 4 keyboard shortcuts”. See http://neo-layout.org/ (hover over “Ebene 4”). When I press RightAlt+e/d, which is mapped to UpArrow/DownArrow in the NEO layout, Chrome does not scroll the page (but used to!). If that’s a separate bug, please let me know whether to file a new one or if there is a separate ticket already open to subscribe to. Thanks.
I'm now running Chromium 38.0.2125.8 (290962), compiled from sources using Gentoo's ebuild, and I still do not have a functioning XCompose. I have dead keys on AltGr+key, and those dead keys combine with the following keystroke. For instance, "AltGr+o, a" yields "å". This works in every other app, whether Qt or Gtk, but it doesn't work in Chromium. In Chromium, I get no characters input at all, not even an "a", which is interesting, as clearly Chromium knows something is supposed to happen but doesn't know what.

Comment 60 by msw@chromium.org, Aug 26 2014

Note potentially related (Windows-specific?) AltGr Issue 247297.
My XCompose also fails in input fields on web pages, not just in the Omnibox.
In reply to #58.

I think we want to handle layer 4 (level 4?) shift as a separate issue. Can you file it as a separate issue?
Filed #408034 about the issue mentioned in comment #58.

Comment 64 by Deleted ...@, Sep 4 2014

The issue is present for me too on Ubuntu 14.04, Google Chrome Version 37.0.2062.94 (64-bit). The symptoms are as described in #59: no key emitted at all, whereas in the rest of the system the composite key works *after disabling iBus*. Keyboard is UK, `.XCompose` is *not* customized (not present).

What I have to add to the report is that, running google-chrome from command line, whenever I press a composite key I get an error on the console such as the following:

[8894:8894:0904/221921:ERROR:browser_main_loop.cc(207)] Gdk: gdk_window_set_user_time called on non-toplevel

env variables are as described in <https://code.google.com/p/chromium/issues/detail?id=360388#c52>:

    GTK_IM_MODULE=xim
    XMODIFIERS=@im=ibus

Xim is disabled (`run_im xim` in the .xinputrc file) and is not running (i.e. `ibus exit` run before running this test). I've also tried removing it altogether from the system and rebooting (as opposite of running `ibus exit`) and it didn't change so, although I would have loved to blame ibus even for this problem, this is not the case.

I just tried this on chrome "Version 39.0.2145.4 dev (64-bit)" with the same result, the compose sequences are not respected.  Any update on when this will be fixed?

Comment 66 by wal...@wjd.nu, Sep 14 2014

I'm with #64: same console error.
Version: 37.0.2062.94 (Ubuntu Trusty), US keyboard with custom .XCompose.

  $ env | egrep 'XMOD|GTK_IM'
  XMODIFIERS=@im=none
  GTK_IM_MODULE=xim

Interesting facts:

- immediately when starting chromium, compose characters *work* in the (already focused) omnibox, but as soon as I leave the omnibox (tab or enter or mouseclick), compose key support is gone and won't come back (and I get the error message in the console).

- when the compose key works, it doesn't do my custom .XCompose characters.

- if ibus is running and I start chromium with XMODIFIERS=@im=ibus, then the compose key works like expected (but I don't get my custom .XCompose keys because that doesn't work with ibus). (this last workaround should allow me to use the default compose characters in chromium while getting .XCompose keys in the rest of the apps.)
 Issue 399864  has been merged into this issue.

Comment 68 by amb...@gmail.com, Sep 21 2014

Same with 38.0.2125.66 beta (64-bit), with xim as the input on a Ubuntu 14.04, with no custom .XCompose file.

I am seeing what #66 described. Compose characters work in the already focused omnibox, but as soon I click anywhere else, it starts throwing errors:

ERROR:browser_main_loop.cc(208)] Gdk: gdk_window_set_user_time called on non-toplevel

Comment 69 by amb...@gmail.com, Sep 21 2014

Adding to my comment #68:

* switching the input to uim instead of xim (via GTK_IM_MODULE) fixes the problem. Tested both with and without a custom .XCompose, and everything works fine, including ctrl+shift+U to enter Unicode characters.

Comment 70 by amlowe@google.com, Oct 9 2014

Cc: amlowe@google.com

Comment 71 by beld...@gmail.com, Oct 18 2014

I have the following settings in .xsession:
GTK_IM_MODULE=xim; export GTK_IM_MODULE
QT_IM_MODULE=xim; export QT_IM_MODULE
XMODIFIERS="@im=none"; export XMODIFIERS

The compose key works when the charset is English, but ignores the same sequences when Russian charset is on.

Chromium version is 38.0.2125.104 (64-bit)
This issue seems to be resolved for me in Chromium 40.0.2214.28 on Gentoo Linux. I have GTK_IM_MODULE=xim in my environment, and I can now use my custom ~/.XCompose sequences.

Comment 73 by Deleted ...@, Dec 18 2014

Confirmed problem fixed in Chromium 40.x, still present in 39.x. Just using the google-chrome-beta package on all my desktops.
Cc: matthewyuan@chromium.org amineer@chromium.org penny...@chromium.org
Labels: Needs-Feedback
Seems like the fix is not yet merged into the latest stable#39.0.2171.95, do we need any merge?

Thanks in-advance!
 Issue 442243  has been merged into this issue.

Comment 76 by amin...@google.com, Dec 29 2014

Given where we are in the 39 release cycle, we'll probably wait until 40 is deployed to stable for the fix.
Cc: -kenjibaheux@chromium.org

Comment 78 by derob...@gmail.com, Jan 26 2015

Confirmed fixed in Debian Chromium build 40.0.2214.91-1. I've tested on two machines which were previously effected by the problem, and that upgrade fixed it on both.

Comment 79 Deleted

Comment 80 by japgo...@gmail.com, Feb 11 2015

This is fixed for me on Arch Linux with Google Chrome 40.0.2214.111.​

Comment 81 by msw@chromium.org, Feb 11 2015

Cc: -msw@chromium.org
I can confirm this is fixed on Arch Linux Chromium Version 40.0.2214.111 (64-bit) as well.
Owner: shuchen@chromium.org
Status: Fixed
I can repro this issue on 42.0.2311.90, but cannot repro on 44.0.2378.0.

Assuming fixed by https://codereview.chromium.org/1068093002/.
Labels: M-44

Sign in to add a comment