maemo.org Bugzilla – Bug 3250
Keys of special characters of the physical keyboard don't work at web text entries
Last modified: 2009-12-08 18:16:06 UTC
You need to
before you can comment on or make changes to this bug.
OS version: 4.2008.23-14
This is the last update for the Diablo pre-release version.
Installed correctly from the tableteer repository with apt-get.
STEPS TO REPRODUCE THE PROBLEM:
1) Get a N810 with spanish keyboard.
2) Open the browser and some webpage with a text entry (the default one, for
3) Try write 'más' with the physical keyboard.
In the text entry is written 'más'.
In the text entry is written 'mas' because the key with the characters (' ` ")
Same happens with the key with the following characters (^ ~)
It happens with the special characters with the spanish keyboard, but could be
what happens too with special characters from other keyboards.
These keys work perfectly in other applications and the address bar of the
Settings->Text input settings->Keyboard layout is 'Español, Français(Canada),
'locale' command output is:
Did this work well before with other diablo pre-releases?
Forwarded this, thanks a lot!
(In reply to comment #1)
> Did this work well before with other diablo pre-releases?
I can't assure 100 % but I've noticed that lately so possibly it has been in
some of the last updates. I also can't say since what update it would be.
Bug has been successfully reproduced internally.
oh right. i looked at this a bit.
afaict there's no way to enter a ':' using the hardware keyboard and that
keylayout. would someone please tell me i'm wrong (and how)?
of note, it is possible to enter:
into the urlbar (well, if you can manage to type : - see above), so it's indeed
somewhat limited to the browser.
the browser uses a gtkplug to embed the browser daemon. my guess (and it'd be
great if someone could confirm this) is that it never worked (post introduction
of the daemon).
(In reply to comment #5)
> afaict there's no way to enter a ':' using the hardware keyboard and that
> keylayout. would someone please tell me i'm wrong (and how)?
If I understand you, it's possible with the spanish keyboard. There is a key
with the following characters (. : _).
Key press = .
Shift (aka arrow up) + key = :
Fn + key = _
anyway, we checked and it isn't gtkplug. next step is to check a bluetooth
keyboard (we couldn't find one today, maybe thursday?)
By pressing "Chr + A" twice I am able to write "á" in browser form fields. I
can write á from the on-screen display too.
The only way I can't enter á is by using the ' + a combination, as the reporter
I don't have a bt keyboard either, but I tried with x11vnc -- same result: I
can't use the ' key to type "á" on my PC keyboard in browser form fields. Works
fine in the address bar.
another thing which it would be great for someone to test is running
Firefox/Thunderbird/Fennec and using the keyboard.
You don't need to run it locally, an ssh forwarded session would be fine.
My test results (N810, spanish hw keyboard):
Test 1: 'ssh -X my-desktop-computer' from the tablet and run iceweasel:
- ' + a works as expected on form fields.
- Chr + a does not work (expected too, as iceweasel is not a maemo app)
Test 2: latest version of Fennec installed on the tablet
- ' + a works as expected too.
- Chr + a does not fully work -- it does not erase the first char. when pressed
fwiw, i don't consider "not working because it's not a maemo app" to be a
correct answer (not your fault). I consider it a bug in the input method
implementation of the hardware keyboard that it doesn't properly interact with
existing IM aware applications.
andre: could you please arrange for a bug to be filed against any future input
methods (hardware, software, imaginary, imagined, real, etc.) requiring them to
inter-operate with applications which support XIM. This is especially true for
applications such as Firefox or Fennec.
webkit-eal does not seem to be affected by this.
Does that mean this bug should be at least workaround-able by editing only open
sourced MicroB engine sources?
erm. (i'm asleep, so please bare with me.)
from memory, the bug is probably that the hildon-input-method is evil and
doesn't play nicely with XIM. If that's the case, the *proper* fix is to fix
If you wanted to make a hack, you could probably construct some evil
gtktextwidget somewhere in eal and have it rebroadcast events to gecko (good
you're welcome to make a straight Xt app which plays with XIM and just lists
the events it gets, that'd enable you to describe what's actually going on and
decide whether it's remotely practical to work around it anywhere else. My gut
feeling is that the answer is it isn't. If you actually care about input
methods at all, this is a much more useful endeavor.
Created an attachment (id=1264) [details]
ugly patch to microb-engine 1.0.4-60.20
Okey, after some hours of boring "blind watchmaker" testing, I found that by
#defining USE_XIM in MicroB and also manually discarding any GdkEventKey whose
keyval is 65027 (the n810 FN key) or 65505 (shift)*, I can get MicroB to
emulate the Fennec behavior as I described in comment #10, save for
autocomplete, which does not work at all now.
This is an acceptable workaround for me. I'm attaching the patch just for
completeness cause it's awful (and also the patch does not define USE_XIM,
change Makefile.in as appropriate).
No clue about why Chr+a no longer works.
Autocomplete behaves weirdly: on keydown, it seems it is going to work
(suggesting words and all that), but disappears on keyup. No clue either.
*If I don't do this, FN key events seem to repeat, so a single FN key press in
a MicroB field results in instant FN-lock activation. Same with Shift.
so... i'm confused... you're patching gecko, adding a USE_XIM bit, and the
final result is something which matches what another gecko gets today already?
(In reply to comment #15)
> so... i'm confused... you're patching gecko, adding a USE_XIM bit, and the
> final result is something which matches what another gecko gets today already?
That would make sense :P, but either way, I'm discarding that idea (enabling
USE_XIM) since I noticed that another GtkWidget was already hildon_im_filtering
my keypress events: GtkMozEmbed.
So I'm now concentrating on microb-eal's gmozillaengine.c , which contains
thousands of lines of hard-to-understand GtkIMContext logic; enough to keep me
entertained for a few days :).
Created an attachment (id=1266) [details]
Proposed fix to 0.3.7 (not clean -- has trace statements)
I hit paydirt: this is a microb-eal bug. GMozillaEngine's IM logic is wrong.
From what I've understood, it seems that it needs to decide whether to forward
forward the Utf8 string H-I-M gives as part of the commit signal (which then
The Utf8 string is always right (capitalized if Shift key down, produces á
correctly, etc.); however, the GDK keypress does not contain information about
dead key state and as such Mozilla cannot synthesize a "á" key press from it.
It can properly synthesize shifts, etc though.
The algorithm microb-eal is currently using can be summarized to this:
if (is_chr_key_pressed) obey_hildon_im();
And seems it was written as part of bug "78162" (I assume internal?)
Which is fine for non-ptes layouts, but of course fails miserably in the
Portuguese-Spanish layout since if a dead key has been pressed the next event
should NOT be forwarded as a GDK key event but as the Utf8 string H-I-M
produces (for the reasons stated above).
Since I'd spent a few days debugging an algorithm in Gecko for the VERY SAME
DECISION process (which is also a cleaner and more generic algorithm) it made
sense to try to port a few bits of it to GMozillaEngine, and that's what this
I think this solution is more elegant than hardcoding the Chr key scancode,
which both my previous solution and the current microb-eal are doing.
Now it works perfectly. Dead keys, autocomplete, shift locks, the Chr key, you
name it :).
You may even want to consider this for Fremantle, if it's still using
microb-eal and a hardware keyboard.
Created an attachment (id=1267) [details]
Proposed patch to microb-eal_0.3.7-1.21
Cleaned it up a bit.
Also, for the sake of completeness, allow me to summarize the algorithm this
patch implements (since I already summarized the current one):
if (hildon_im_filters_this_key && strcmp(what_hildon_im_says,
for reference. Bug 78162 Keyboard shortcuts don't work properly in Google
1. Open google reader
2. try to press G U (shortcut for subscriptions)
3a. use directional navigation keys (arrows)
3b. type some letter that corresponds to some feed
3a -> focus moves from one to the next feed
3b -> The feeds identified by the letters pressed are shown
3a -> focus moves just once and then the menu disappears
3b -> The feeds are not shown.
This happens also using the other shortcuts (example G T for tags, and so on)
for "Real Key Events".... but unfortunately our ...
manual IM commits (to make Chr key works properly) and
blocking that events from mozilla handlers...
(In reply to comment #19)
> 1. Open google reader
> 2. try to press G U (shortcut for subscriptions)
> 3a. use directional navigation keys (arrows)
> 3b. type some letter that corresponds to some feed
> 3a -> focus moves from one to the next feed
> 3b -> The feeds identified by the letters pressed are shown
Thanks. Seems to work fine (other than being slow here).
Created an attachment (id=1268) [details]
Untested patch to microb-eal trunk r3928
The same patch refreshed for current trunk (I still don't know all of the
diff/patch intricacies e.g. why it generates incredibly long hunks sometimes
which are nearly unmatchable).
Totally untested though (not even for compile errors!) since I don't have the
Fremantle SDK. Try at your own risk ;)
Is it already too late for this to be FiF? Is there another workaround planned,
or has the bug been fixed internally?
I'll consider it a disaster if dead keys don't work in the released device
I've been using the above patch for a few weeks in my N810 (Diablo) seemingly
(In reply to comment #21)
> Untested patch to microb-eal trunk r3928
I'm a little bit afraid that
https://garage.maemo.org/svn/browser/mozilla/trunk/microb-eal/ is not the real
trunk but that Nokia is instead hiding the Fremantle Browser trunk for
competitive/whatever reasons. :-/
Can somebody please come up with an explicit good testcase so I can try to
reproduce in current Fremantle?
Comment 19 is still too vague for me...
1. Have a hardware keyboard layout
1. Start browser in Fremantle
2. Enter address:
3. Click Enter
4. Get HTML file with textarea prefilled with más
5. Go to textarea
6. Enter más again (á created by compositing it - first accent, than a)
WORKS in Fremantle.
Hence need another testcase, preferably broken. ;-)
Oh, thanks, good to know -- working hardware dead keys should be enough to
consider this fixed since this bug was "created" while designing a workaround
for the Google Reader issue, and I doubt Nokians fixed the bug by removing the
Google Reader workaround ;)
Ideally Google Reader should be the test for the Google Reader bug, but a quick
google search reveals what I believe is a simpler testcase:
See the "demo" section, press "j" hw key, then see if "has been called"
appears. The other shortcuts work too, but Shift is not sticky since there's no
textfield and as such the hildon-input-method gui does not appear (at least on
"Accidentally not possible to reproduce in fremantle, but probably still
technically broken", after trying a testcase in Google Reader provided by
Removing "offensive" flag (I wonder how I accidentially set this).
So this works fine for me in Fremantle. If the bug is still existing it is at
least not visible anymore.
If this ever becomes an issue again please do REOPEN this ticket.
Marking patches of interest to Diablo (Maemo4) community updates, please excuse
I have Diablo 5.2008.43-7 in my n810 and can't use accents in microb just
like the original reporter (thought my device's language is pt-BR). I see
there's a patch that fixs it but I don't know how to install it. Can you help
Thanks in advance,
(In reply to comment #31)
> I see there's a patch that fixs it but I don't know how to install it.
If you are not into compiling software yourself, there is no easy way to
"install" the patch.