Special keys/symbols/emoji not showing up in chromium-browser

[Mark Huijgen]

I'm having some trouble using onboard with chromium-browser. All normal keys that are on my normal physical keyboard appear within chromium-browser when clicked in onboard.

However letters like é ê from holding the e and currency symbols from the symbols £ ¥ are not showing up. Same for the emoji's. They do work in other (gnome) applications and also in firefox and xterm.

Entering these special chars in another application and then copy pasting them into chromium-browser does work.

Using:
Ubuntu 14.04
chromium-browser 34.0.1847.116-0ubuntu2
onboard 1.0.0-0ubuntu4

In a standard gnome-session (no unity).

[marmuta (marmuta)]

Confirming, same behavior here. On first glance, I'm not very hopeful we can fix this from Onboard, though.

For some background, Onboard has two ways of getting what you type to applications:

1) By directly inserting text into text entries via AT-SPI. This is preferred, it's the short path, it basically never fails. However it requires solid support for AT-SPI. We basically have this only in gtk-3 applications like gedit, epiphany, nautilus, etc.

2) By simulating key-strokes via XTest. There are various known problems with this path, for example firefox losing fast key-strokes and certain special characters unintentionally triggering hotkeys.

Chromium falls into category 2), because support for AT-SPI is basically non-existent there. However it gets the same treatment as firefox, and there special characters type well enough.

I see two ways forward: chromium provides AT-SPI text interfaces, or more realistically we try to figure out where the key-strokes get lost in chromium.

[Mark Huijgen (mark-sf-net)]

I've been digging around in the source for chromium-browser 34.0.1847.116

The first function in ui/events/keycodes/keyboard_code_conversion_x.cc
 KeyboardCode KeyboardCodeFromXKeyEvent(XEvent* xev)
looks up the keysym from the xev with XLookupString(&xev->xkey, NULL, 0, &keysym, NULL);

Then it filters the keysym through function below it called
KeyboardCode KeyboardCodeFromXKeysym(unsigned int keysym)

This filters the keysym against a list of known keys it seems and for anything else it returns VKEY_UNKNOWN. This happens for all the keys from onboard that are currently not working in chrome, they are being filtered out in this function. Yey for platform independat keyboard handling of chrome...

I've done a quick and dirty hack in this filter function by replacing its last return VKEY_UNKOWN at the bottom of the function with
return static_cast<KeyboardCode>(keysym);

This makes almost all of the keys from onboard work in the various ui elements, though not all, the yen symbol ¥ keysym c2a5 seems to be handled by chrome in some weird way, the input element looses focus and no character is added.

[marmuta (marmuta)]

That's some fine detective work, thanks. So the key-strokes are indeed actively filtered out in chromium. I'm just guessing, but maybe this is meant to protect from URL spoofing with international characters. Anyway, we should let the developers there know that this causes problems with screen keyboards. Could you open an upstream bug report?

[Mark Huijgen (mark-sf-net)]

Reported in chromium as #373756
https://code.google.com/p/chromium/issues/detail?id=373756

[Mark Huijgen (mark-sf-net)]

There have been a few replies from chrome devs on the upstream bug report. They think onscreen keyboard should send IME composing events instead of simulating key events.

[marmuta (marmuta)]

Thanks, for the hint. I think I'm going to take a closer look at what's needed to become an IM module/server. If that helps us to side-step all the issues with key-stroke generation and perhaps even reduce the dependence on AT-SPI, I'm for it.

What I I'm slightly worried about is Chromium not implementing "delete-surrounding" and "retrieve-surrounding". This kind of variation between applications/toolkits is what haunted us before with AT-SPI. If I'm not mistaken we still wouldn't be able to show word suggestions for Chromium then.