Bug 3250 - (int-86461) Keys of special characters of the physical keyboard don't work at web text entries
(int-86461)
: Keys of special characters of the physical keyboard don't work at web text en...
Status: RESOLVED WORKSFORME
Product: Browser
MicroB engine
: 4.1 (4.2008.23-14)
: N810 Maemo
: Medium major with 2 votes (vote)
: 5.0 (1.2009.41-10)
Assigned To: Oleg Romashin
: microb-bugs
: data:text/html;charset=utf-8,<textare...
: community-diablo, patch
:
:
  Show dependency tree
 
Reported: 2008-06-15 13:34 UTC by Daniel Martin Yerga
Modified: 2009-12-08 18:16 UTC (History)
5 users (show)

See Also:


Attachments
ugly patch to microb-engine 1.0.4-60.20 (1.73 KB, patch)
2009-07-10 04:32 UTC, Javier S. Pedro
Details
Proposed fix to 0.3.7 (not clean -- has trace statements) (7.95 KB, patch)
2009-07-11 16:11 UTC, Javier S. Pedro
Details
Proposed patch to microb-eal_0.3.7-1.21 (7.33 KB, patch)
2009-07-11 20:50 UTC, Javier S. Pedro
Details
Untested patch to microb-eal trunk r3928 (7.32 KB, patch)
2009-07-12 13:51 UTC, Javier S. Pedro
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Daniel Martin Yerga (reporter) 2008-06-15 13:34:33 UTC
SOFTWARE VERSION:
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. 

microb-engine: 1.0.4-60.9
libgtkmozembed: 1.2.3-5.4
microb-eal: 0.3.7-1.15


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
example).
3) Try write 'más' with the physical keyboard.


EXPECTED OUTCOME:

In the text entry is written 'más'.


ACTUAL OUTCOME:

In the text entry is written 'mas' because the key with the characters (' ` ")
doesn't work.
Same happens with the key with the following characters (^ ~)  


REPRODUCIBILITY:
Always


OTHER COMMENTS:
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
browser.

Settings->Text input settings->Keyboard layout is 'Español, Français(Canada),
Português'

'locale' command output is:
LANG=es_ES
LC_CTYPE="es_ES"
LC_NUMERIC="es_ES"
LC_TIME="es_ES"
LC_COLLATE="es_ES"
LC_MONETARY="es_ES"
LC_MESSAGES=en_GB
LC_PAPER="es_ES"
LC_NAME="es_ES"
LC_ADDRESS="es_ES"
LC_TELEPHONE="es_ES"
LC_MEASUREMENT="es_ES"
LC_IDENTIFICATION="es_ES"
LC_ALL=
Comment 1 Andre Klapper maemo.org 2008-06-16 12:22:08 UTC
Did this work well before with other diablo pre-releases?
Comment 2 Andre Klapper maemo.org 2008-06-16 12:42:10 UTC
Forwarded this, thanks a lot!
Comment 3 Daniel Martin Yerga (reporter) 2008-06-16 13:37:35 UTC
(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.
Comment 4 Andre Klapper maemo.org 2008-06-17 13:56:24 UTC
Bug has been successfully reproduced internally.
Comment 5 timeless 2008-06-17 16:52:16 UTC
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:
data:text/html;charset=utf-8,<textarea>más

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).
Comment 6 Daniel Martin Yerga (reporter) 2008-06-17 18:04:54 UTC
(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 = _
Comment 7 timeless 2008-06-17 19:39:41 UTC
thanks.

anyway, we checked and it isn't gtkplug. next step is to check a bluetooth
keyboard (we couldn't find one today, maybe thursday?)
Comment 8 Javier S. Pedro 2009-03-21 16:31:45 UTC
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
mentioned. 

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.
Comment 9 timeless 2009-03-21 22:05:13 UTC
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.
Comment 10 Javier S. Pedro 2009-03-22 00:06:52 UTC
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
twice.
Comment 11 timeless 2009-03-22 00:57:08 UTC
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.
http://www.mozilla.org/projects/intl/input-method-spec.html

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.
Comment 12 Javier S. Pedro 2009-07-08 02:29:22 UTC
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?
Comment 13 timeless 2009-07-08 10:13:15 UTC
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
hildon-input-method.

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

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.
Comment 14 Javier S. Pedro 2009-07-10 04:32:13 UTC
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.
Comment 15 timeless 2009-07-10 05:59:03 UTC
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?
Comment 16 Javier S. Pedro 2009-07-11 04:55:00 UTC
(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 :).
Comment 17 Javier S. Pedro 2009-07-11 16:11:10 UTC
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
GDK keypress events to Mozilla (I assume for JavaScript to process) or just
forward the Utf8 string H-I-M gives as part of the commit signal (which then
cannot be processed by JavaScript).
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();
else forward_key_press();
And seems it was written as part of bug "78162" (I assume internal?)
workaround.

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
patch does. 
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.
Comment 18 Javier S. Pedro 2009-07-11 20:50:48 UTC
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,
what_we_know_from_the_gdk_event)!=0) obey_hildon_im();
else forward_key_press();
Comment 19 timeless 2009-07-12 03:38:30 UTC
for reference. Bug 78162 Keyboard shortcuts don't work properly in Google
Reader
1. Open google reader
2. try to press G U (shortcut for subscriptions)
3a. use directional navigation keys (arrows)
or 
3b. type some letter that corresponds to some feed

EXPECTED OUTCOME:
3a -> focus moves from one to the next feed 
3b -> The feeds identified by the letters pressed are shown
ACTUAL OUTCOME:
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)

initial explanation:
Google reader has JavaScript implementation of key event which are listening
for "Real Key Events".... but unfortunately our ...
manual IM commits (to make Chr key works properly) and
blocking that events from mozilla handlers...
Comment 20 Javier S. Pedro 2009-07-12 13:34:27 UTC
(In reply to comment #19)
> 1. Open google reader
> 2. try to press G U (shortcut for subscriptions)
> 3a. use directional navigation keys (arrows)
> or 
> 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).
Comment 21 Javier S. Pedro 2009-07-12 13:51:58 UTC
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 ;)
Comment 22 Javier S. Pedro 2009-08-03 18:52:04 UTC
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
browser.

I've been using the above patch for a few weeks in my N810 (Diablo) seemingly
without problems.
Comment 23 Andre Klapper maemo.org 2009-08-03 23:11:51 UTC
(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. :-/
Comment 24 Andre Klapper maemo.org 2009-08-04 00:22:30 UTC
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...
Comment 25 Andre Klapper maemo.org 2009-08-04 00:42:27 UTC
1. Have a hardware keyboard layout
1. Start browser in Fremantle
2. Enter address:
   data:text/html;charset=utf-8,<textarea>más
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. ;-)
Comment 26 Javier S. Pedro 2009-08-04 01:06:01 UTC
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:
http://www.acunote.com/open-source/javascript-keyboard-shortcuts

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
Diablo).
Comment 27 Andre Klapper maemo.org 2009-08-04 02:35:43 UTC
"Accidentally not possible to reproduce in fremantle, but probably still
technically broken", after trying a testcase in Google Reader provided by
timeless.
Comment 28 Andre Klapper maemo.org 2009-08-10 13:05:58 UTC
Removing "offensive" flag (I wonder how I accidentially set this).
Comment 29 Andre Klapper maemo.org 2009-09-24 14:13:41 UTC
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.
Thanks.
Comment 30 Lucas Maneos 2009-10-22 07:57:18 UTC
Marking patches of interest to Diablo (Maemo4) community updates, please excuse
the noise.
Comment 31 Danilo Luvizotto 2009-12-08 17:33:00 UTC
Hi,

   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
me?

Thanks in advance,
Danilo Luvizotto
Comment 32 Andre Klapper maemo.org 2009-12-08 18:16:06 UTC
(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.