Compose and dead keys stopped working with XIM after upgrade to 16.04

Bug #1573755 reported by Jan Claeys on 2016-04-22
146
This bug affects 31 people
Affects Status Importance Assigned to Milestone
firefox (Ubuntu)
High
Unassigned
gnome-terminal (Ubuntu)
High
Unassigned
ibus (Ubuntu)
High
Unassigned
libx11 (Ubuntu)
High
Unassigned
nautilus (Ubuntu)
High
Unassigned
thunderbird (Ubuntu)
High
Unassigned
xkeyboard-config (Ubuntu)
High
Unassigned

Bug Description

After upgrading to 16.04, entering characters using dead keys and using the Compose key stopped working in Gnome Terminal, acting like they are normal (non-dead) keys.

Other applications, even those who use the same libvte (e.g. ROXTerm), don't have this issue.

This happens with both the "Belgian" and "English international with AltGr dead keys" layouts.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: gnome-terminal 3.18.3-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Apr 22 20:45:33 2016
InstallationDate: Installed on 2013-12-16 (857 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
SourcePackage: gnome-terminal
UpgradeStatus: Upgraded to xenial on 2016-04-22 (0 days ago)

Jan Claeys (janc) wrote :
Jan Claeys (janc) wrote :

Meanwhile I found out that this also affects nautilus, but not e.g. Gedit, Firefox, HexChat, etc.

And it only happens when XIM is selected as input method.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Changed in nautilus (Ubuntu):
status: New → Confirmed
Manuel Lucena (mlucena) wrote :

Same with Spanish Keyboard

I can confirm the same with 16.04 and Fr-Ca, i can type _è_ but in gnome-terminal I get _`e_

A new user isn't affected by this problem, how would one reset the gnome-terminal configuration without wiping the whole profile? :)

rm -f ~/.config/dconf/user solved it for me.

Doudz (sebastien-ramage) wrote :

Same problem with French Keyboard, doing rm -f ~/.config/dconf/user didn't change anything for me

For example I can't type û in some app , it makes ^u

Some examples :

App working :
Chromium, Firefox, LibreOffice, Unity, gedit, remmina

Non working
Thunderbird, Nautilus, Gnome Terminal

Jan Claeys (janc) wrote :

You can possibly work around this by selecting another input method (IM) with 'im-config' or by removing ~/.xinputrc (which selects the default for your locale) and then reboot (or restart X11—log out & back in is not always enough).

The default IM for most languages is 'ibus' which you can configure with 'ibus-setup' if necessary (but only after the X restart!).

For some reason the ibus developers think it's funny to show a "smiley face" during entering of a Compose sequence, but otherwise it seems to work okay now.

Jan Claeys (janc) wrote :

BTW: always run 'im-config' and 'ibus-setup' as your regular user (unless you really know what you are doing)!

Manuel Lucena (mlucena) wrote :

Removing ~/.xinputrc has solved the problem for me.

Doudz (sebastien-ramage) wrote :

removing ~/.xinputrc and using im-config to set "default" to use /etc/default/im-config solved the problem for me

Changed in gnome-terminal (Ubuntu):
importance: Undecided → High
Changed in nautilus (Ubuntu):
importance: Undecided → High
Piotr P. Karwasz (chopinhauer) wrote :

I believe it is an ibus-daemon bug. I had the problem at least in gnome-terminal, firefox (but not under Unity), thunderbird. I solved it less brutally than flushing the whole user DConf database by resetting one key:

dconf reset /org gnome/desktop/interface/gtk-im-module

which contained the value 'gtk-im-context-simple'.

It worked:

* for gnome-terminal after logging again, restarting the program wasn't enough.
* for Firefox and Thunderbird only after restarting the system. The only user program that didn't restart after a relog was 'ibus-daemon', hence I believe it is his bug.

What makes me wonder is why the Compose key worked on Firefox only under Unity and not GNOME 3. There might be a second bug there.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Changed in thunderbird (Ubuntu):
status: New → Confirmed
Changed in ibus (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Changed in firefox (Ubuntu):
importance: Undecided → High
Changed in thunderbird (Ubuntu):
importance: Undecided → High
Changed in firefox (Ubuntu):
status: Confirmed → Invalid
Changed in gnome-terminal (Ubuntu):
status: Confirmed → Invalid
Changed in nautilus (Ubuntu):
status: Confirmed → Invalid
Changed in thunderbird (Ubuntu):
status: Confirmed → Invalid
summary: - compose and dead keys stopped working in gnome terminal
+ Compose and dead keys stopped working

I can reproduce this XIM problem on a system which was upgraded to 16.04, but not on a fresh Ubuntu 16.04. However: If I create and switch to a new user, the problem is not present. In other words: Some leftovers from previous version(s) in the home directory of my main user prevent the XIM input method from working properly.

Resetting the gtk-im-module gsettings key, as mentioned by Piotr, doesn't help for me. Neither does removing of the whole gsettings database ~/.config/dconf/user

For the record: On Ubuntu and most flavors, switching to some other input method can be done from the Language Support GUI. Doing so changes the ~/.xinputrc file instead of removing it.

summary: - Compose and dead keys stopped working
+ Compose and dead keys stopped working with XIM after upgrade to 16.04
Gunnar Hjalmarsson (gunnarhj) wrote :

This bug report was one reason why I submitted <https://launchpad.net/bugs/1605408>. Considering that XIM currently may cause problems in an unpredictable manner, we'd better stop setting it automatically in certain flavors, at least until the root cause has been spotted and the problem fixed.

Adding xkeyboard-config and libx11 as affected packages. Don't think that this is an ibus issue, but leaving it there for now.

Changed in libx11 (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Changed in xkeyboard-config (Ubuntu):
importance: Undecided → High
status: New → Confirmed

For me, the behaviour is completely the opposite of those reported by others:

Apps with Compose key working:
- Gnome Terminal, Dash search field

Apps with Compose key ineffective
- Gedit, LibreOffice, Chrome, Firefox

But when creating a new user and copying my .XCompose to him, for that user the Compose key works in all applications.

Otto Piscus (voytekl) wrote :

I am in the same situation as Rudiger, with the compose key working in Terminal and Dash but not anywhere else I can find. System upgraded to 16.04. All fixes listed above attempted, with no improvement.

Not sure if this helps, but I also had a strange behaviour in terminal for a while where the operation of the compose key appeared to be reversed. ie. I would press ' then e and get é without having first pressed compose. If I first pressed compose then I would get 'e. The compose key still did nothing in libreoffice, firefox etc. This has now stopped, but not sure which operation made it change.

Coeur Noir (coeur-noir) wrote :

^e ^i …since yesterday dead keys don't work anymore on my ubuntu … 14.04.5 LTS.

And since yesterday I have problems with accented letters in 14.04 - same problem I already have on 16.04 here bug #1599516

Pierre Abbat (phma-a) wrote :

I upgraded from Trusty to Xenial. Before the upgrade, the compose key was working in all applications, except maybe Torchat (which I hadn't used for months before the upgrade). After the upgrade:
*Konqueror works properly when I use the Dvorak layout and the compose key. If, however, I switch to Greek and attempt to type an accented iota, I get an accented c (ć) instead. (The accent is a dead key in the Greek layout.)
*In Kate, Kwrite, and Kmail, it works only if the resulting character code is less than 256 (I can type ÿ, but not Ÿ, which I have to copy from Konqueror).
*In Firefox, Torchat, and Konsole, it does not work at all. I hit compose and two keys that should make a character, but get nothing.

Bas Roufs (basroufs) wrote :
Download full text (3.7 KiB)

Hello Everybody.

At this dead keys problem, I stumble upon now - however, so far, just in LibreOffice. Ever since a few weeks, I work at a fresh install of Kubuntu 16.04 - along with KDE Plasma 5.6.5, installed via the Kubuntu ppa backports. Dead keys work in all applications except LibreOffice - version 5.1.4.2. I am using the keyboard "USA International". A character like ä is no problem in most of the applications. They same applies for e.g. the double quotation mark (") - the key that needs to be pressed first in order to get ä. However, in Libreoffice in my configuration as summarised here, signs like " and ä do not show up. I have similar problems with characters like à, é, ë, ñ. č, etc. Also signs like `, ~ or ' do not show up in Writer or any other Libreoffice application. It does not matter whether I work in Dutch, English, Italian, French, German or whatever - the problem remains the same - however, as I said, just in LibreOffice.

The only workaround I have found so far is editing a text in another application (Kate, BlueFish or whatever) and copy-pasting it into LibreOffice. The workaround mentioned in comment 6 does not work here. I DO manage to invoke libreoffice from the command line - "libreoffice" does end up in the following sequence:

========================================

bas@Viaconsensus-transit:~$ unset XMODIFIERS && libreoffice &
[1] 5908
bas@Viaconsensus-transit:~$ W: Unknown node under /registry/extlang: deprecated
W: Unknown node under /registry/grandfathered: comments
W: Unknown node under /registry/grandfathered: comments
X Error: BadMatch (invalid parameter attributes) 8
  Major opcode: 42 (X_SetInputFocus)
  Resource id: 0x7c02342

========================================

However, the problem is not being fixed like this.

Variants like "libreoffice4.2" or "libreoffice5" do not produce any result.
On the other hand - the simple command line command "libreoffice", without anything else, is already enough to invoke that application. During my main working session of today, Tuesday 20 December 2016, I have done so by purpose. Here is the report I get from this working session.

=======================================

bas@Viaconsensus-transit:~$ libreoffice
W: Unknown node under /registry/extlang: deprecated
W: Unknown node under /registry/grandfathered: comments
W: Unknown node under /registry/grandfathered: comments
X Error: BadMatch (invalid parameter attributes) 8
  Major opcode: 42 (X_SetInputFocus)
  Resource id: 0x7404614
X Error: BadMatch (invalid parameter attributes) 8
  Major opcode: 42 (X_SetInputFocus)
  Resource id: 0x7406fbd
X Error: BadMatch (invalid parameter attributes) 8
  Major opcode: 42 (X_SetInputFocus)
  Resource id: 0x74079cf
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
kbuildsycoca4 running...
LibreOffice(2110) KSambaSharePrivate::findSmbConf: KSambaShare: Could not find smb.conf!
X Error: BadMatch (invalid parameter...

Read more...

Hachmann (marenhachmann) wrote :

I've got this problem on Linux Mint 18 Xfce (sorry...), German keyboard, for kde based apps, ever since I upgraded from 14.04 to 16.04.

konsole and kate are the applications where it hurts most.

Neither Compose key+accent+char nor typing the accent, then the char, work for me

(I only need ^, ´ and `, which work fine in other apps. I'd like to be able to use regexes in kate and write the occasional French translation...).

@Pierre: our problems appear similar. Did you find a solution?

Hachmann (marenhachmann) wrote :

Installing IBus and setting to use it fixed it for me.

Gunnar Hjalmarsson (gunnarhj) wrote :

@Hachmann: Yeah, it seems to be related to XIM, and several users have reported that switching to input method IBus (or "none") fixes it.

Has anybody tried to make XIM work by simply removing the cache in ~/.cache/<application>?

Hachmann (marenhachmann) wrote :

@Gunnar Hjalmarsson:

It was set to 'none' before, so maybe mine is a different bug, then?

(XIM wasn't available for choice in the LM settings dialog for input method, I didn't know how to find out if it was used, but not displayed.).

Gunnar Hjalmarsson (gunnarhj) wrote :

@Hachmann: Well, I forgot that you are on Linux Mint...

At the release of Ubuntu 16.04 "none" meant actually "XIM". It has been changed via updates, so on an updated Ubuntu 16.04 you have both a "none" option (actually setting "none") and a "XIM" option. I suspect that those changes have not been taken into account on Linux Mint. (They use a modified package.)

So probably also you had a XIM problem.

Hachmann (marenhachmann) wrote :

Thank you, @Gunnar Hjalmarsson. I'm still on LM18, maybe update to 18.1 when available for Xfce version will take up those changes.

Unfortunately, fixing this caused a different kate problem now... Can't paste with Ctrl+V (just in case anyone encounters the same as a result of following my path: pasting works for me when kate's snippet dialog isn't visible).
Now I'll need to decide which problem is the one that bugs me more - no accents, or no pasting with snippet dialog open... Seems these input methods are entangled with very unexpected things. Must be a programmer's hell...! I think I'll create a snippet with accented letters and go with XIM :-\

Gunnar Hjalmarsson (gunnarhj) wrote :

Maybe there is a Mint specific issue too, and if so you may want to file a Mint bug.

Hachmann (marenhachmann) wrote :

Yes, who knows. I'll wait until 18.1 is available, and if it's not solved, then I'll investigate further.
Thank you, @Gunnar Hjalmarsson!

Harald W Griesshammer (hgrie) wrote :

ubuntu 16.04 unity: find same problem that .XCompose with alt-right key works in terminal and terminal-based applications (vi, yes I am that old) -- but not in firefox, libreoffice, thunderbird, emacs, etc.

In my case, rm -f ~/.config/dconf/user did not work, nor did any of the other tricks.

Maybe this sheds light on things: my Settings-> Language lists "IBus" as keyboard input method, but ibus does not run on startup/login. Instead, ibus-setup starts with message that demon is not running. And yes, I did follow the proposed fix ("make IBus kbd input method in Languages") -- that did not help. However, after just starting ibus-setup and closing it again, special characters suddenly work in all applications.

However, just starting ibus from terminal as ibus-daemon -d does not work.

There are some ibus-setup messages on the terminal:
/usr/share/ibus/setup/main.py:38: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk
/usr/share/ibus/setup/main.py:39: PyGIWarning: IBus was imported without specifying a version first. Use gi.require_version('IBus', '1.0') before import to ensure that the right version gets loaded.
  from gi.repository import IBus

Can that bring you closer to a solution?

Also affects me on Lubuntu 16.04.

Installing IBus (sudo apt ibus) and using Preferences > Language Support to change the Keyboard input method system to IBus, followed by a system reboot, has fixed the issue (compose:ralt in Keyboard Layout Handler now functions as expected).

Otto Piscus (voytekl) wrote :

The fix suggested by hgrie works for me. ibus-setup is running ibus-daemon, which immediately fixed the issue and lasts until logout.

I note that adding 'ibus-daemon --xim' as a startup application is a permanent fix for the issue in my case.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers