Bug 3407 (int-86642)

Summary: Input language switching does not work in browser entry fields
Product: [Maemo Official Platform] Desktop platform Reporter: Andrew Zabolotny <anpaza>
Component: Input method frameworkAssignee: Mohammad Anwari <mdamt>
Status: RESOLVED WONTFIX QA Contact: input-method-framework-bugs
Severity: normal    
Priority: Medium CC: andre_klapper, anpaza, karstenb, maemo, timeless
Version: 4.1 (4.2008.23-14)   
Target Milestone: 4.1.2   
Hardware: N810   
OS: Maemo   

Description Andrew Zabolotny (reporter) 2008-07-06 10:45:11 UTC
SOFTWARE VERSION: 4.2008.23-14

STEPS TO REPRODUCE THE PROBLEM:
1. Open a new browser window (with the google search)
2. Activate the search string input field (usually this happens by default)
3. Enter a few letters
4. Try to switch the language by pressing Ctrl+Chr. A popup saying the language
has been switched appears.
5. Enter a few letters. In most cases you will get the letters in the same
alphabet as in #3. But sometimes (seldom) the switching will actually occur, so
if this does not work, try to switch the input language forth and back a few
times.
6. If you activate a non-engine input field (for example, the address entry
field at bottom) and switch the language, and then activate the in-browser
input field again, the language will be switched.

Actually input language switching does not work on any entry field, I have
observed this on google mail when trying to enter a message in Russian.

REPRODUCIBILITY: always

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; ru-RU; rv:1.9)
Gecko/2008061712 Fedora/3.0-1.fc9 Firefox/3.0
Comment 1 timeless 2008-07-06 13:35:45 UTC
there's an internal report for this...
Comment 2 Mohammad Anwari maemo.org 2008-07-07 14:02:26 UTC
Fixed in the internal revision.
Comment 3 Lucas Maneos 2008-07-12 16:40:10 UTC
Hi Mohammad,

Is this the same as #2501, and is there a rough ETA for a release of the fix?

FWIW, step 6 above doesn't work here (also N810/4.2008.23-14). I can still
never produce 2nd language characters, in any application or field, even when
the 2nd language is set to Russian.
Comment 4 Karsten Bräckelmann 2008-07-14 23:13:58 UTC
*** Bug 2501 has been marked as a duplicate of this bug. ***
Comment 5 Karsten Bräckelmann 2008-07-14 23:16:32 UTC
Re-opening, since the existing fix doesn't resolve it properly and completely.

Lucas, you are correct that bug 2501 is the same issue, thanks.
Comment 6 Karsten Bräckelmann 2008-07-14 23:18:27 UTC
Also, confirming for obvious reasons.
Comment 7 Lucas Maneos 2008-08-02 16:25:29 UTC
I just discovered /usr/bin/hildon-im-xkbtool, which came in package
hildon-im-wc, ("Western word completion plugin for slide keyboard") of all
things.

With it I can switch slide keyboard layouts from the command line (yay!), for
example:

hildon-im-xkbtool --id=3 -l gr -m pc105

but there are some side effects:

- FN, CHR, & SHIFT-SPACE stop working
- the D-pad middle button becomes an ENTER key

Launching the text input settings control panel applet and tapping OK resets
the keyboard state.

The side effects may be due to "pc105" being the wrong keyboard model.  The
correct one seems to be "nokiarx44":

~ $ hildon-im-xkbtool -g
Internal keyboard:
Model: nokiarx44
Layout: us
Delay: 600
Interval: 50

but specifying that fails with "GLIB WARNING ** default - Error loading
keyboard description".  The only models defined /usr/share/X11/xkb/rules/base*
are "pc105" and "nokiasu8w".

xev shows these events for FN & CHR respectively under normal conditions:

KeyPress event, serial 20, synthetic NO, window 0x1e00001,
    root 0x3e, subw 0x0, time 2206035085, (655,-33), root:(735,27),
    state 0x0, keycode 216 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XLookupString gives 0 characters:  ""

KeyPress event, serial 23, synthetic NO, window 0x1e00001,
    root 0x3e, subw 0x0, time 2206041322, (655,-33), root:(735,27),
    state 0x0, keycode 135 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 characters:  ""

but these when switched with hildon-im-xkbtool (both pc105 & nokiasu8w models
give the same results):

KeyPress event, serial 20, synthetic NO, window 0x1e00001,
    root 0x3e, subw 0x0, time 2206169688, (655,-33), root:(735,27),
    state 0x0, keycode 216 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 characters:  ""

KeyPress event, serial 23, synthetic NO, window 0x1e00001,
    root 0x3e, subw 0x0, time 2206171240, (655,-33), root:(735,27),
    state 0x0, keycode 135 (keysym 0xff67, Menu), same_screen YES,
    XLookupString gives 0 characters:  ""
Comment 8 Andre Klapper maemo.org 2008-08-08 12:29:37 UTC
Comment 2 was incorrect here, but this now has been fixed internally.
The next release of hildon-input-method-plugins will include the fix.
Please verify that it's fixed for you after it has been released.
Comment 9 Lucas Maneos 2008-08-11 13:41:57 UTC
(In reply to comment #8)
> The next release of hildon-input-method-plugins will include the fix.

Is that the correct package name?  It doesn't seem to exist.  The closest I can
find is hildon-input-method-plugins-western, which doesn't actually contain
anything.

> Please verify that it's fixed for you after it has been released.

FWIW, I see no change in 4.2008.30-2.  Was today's update supposed to contain
the fix, or should we wait some more?
Comment 10 Andre Klapper maemo.org 2008-08-11 14:31:33 UTC
(In reply to comment #9)
> FWIW, I see no change in 4.2008.30-2.  Was today's update supposed to contain
> the fix, or should we wait some more?

It's not in today's update, unfortunately - this was fixed after week 30.
See the "30" in the name of the update - now it's week 33 that the update has
been made available.
No idea when the next update will be made available, I'm not involved in that
process. :-/
Comment 11 Andre Klapper maemo.org 2008-08-29 14:13:54 UTC
Fixed in package
hildon-input-method-plugins 3.8.39-1
which is part of the internal build version
4.2008.32

Any public update released with or after this build version will include the
fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.
Comment 12 Andre Klapper maemo.org 2008-09-01 03:32:49 UTC
Reopening - this has not yet been fixed.
Comment 13 Andre Klapper maemo.org 2008-11-12 17:17:54 UTC
This is only partially fixed.
What is and will NOT be fixed (hence WONTFIX, according to Nokia) is this
testcase:

"1. Open new browser window.
2. Focus on google search string.
3. Switch layout.
Switching from Russian layout to English works as expected.
Switching from English layout to Russian doesn't work properly:
Press ctrl-chr and immediately begin typing - Keyboard layout is still English
and doesn't switch.
Press ctrl-chr, wait until banner hides and just then begin typing - Keyboard
layout is Russian.
So, user should wait until banner hides. Back switching to English works
immediately."
Comment 14 Lucas Maneos 2008-11-12 20:05:40 UTC
That's very disappointing to hear :-(

Just to make the scope of this bug clear, it's not confined to browser entry
fields and Russian but it affects physical keyboard input system-wide, with any
language (cf bug 2501).

FWIW the on-device help on 4.2008.36-5 still advertises physical keyboard input
language switching as working, supported functionality (Text input methods >
Integrated keyboard):

> The integrated keyboard can vary depending on the device sales region, but
> the keyboard can still provide two different text input languages at the
> same time.  To switch between two keyboard layouts, press Chr and Ctrl
> simultaneously.

This has never worked with any firmware/update version released so far.

What is the scope of the WONTFIX resolution?  Does it mean Nokia won't fix
language switching in Diablo/N810 or will this also remain broken in Fremantle
and future devices?

Finally, is this something the community help with?  Is the source of the
relevant bits open and if so can we have some pointers to the appropriate
places and a brief description of what the blocker issues are?
Comment 15 Andrew Zabolotny (reporter) 2008-11-14 23:55:13 UTC
I don't understand what you two are talking about, it works fine for me since
last update.

Andre, your testcase works fine for me. I can press Ctrl+Chr and then start
typing immediately, and the switch always happens as expected, no matter of the
switch direction.

Lucas, "This has never worked with any firmware/update version released so
far", this is wrong, it always worked for me, just that it had problems with
Mozilla which are fixed now.
Comment 16 Lucas Maneos 2008-11-15 19:28:08 UTC
(In reply to comment #15)
> Lucas, "This has never worked with any firmware/update version released so
> far", this is wrong, it always worked for me, just that it had problems with
> Mozilla which are fixed now.

Interesting. Here it has never worked, on either of two N810s with the
following details:

$ cat /proc/component_version 
product     RX-44
hw-build    0801
nolo        1.1.16
$ env | grep OSSO
OSSO_PRODUCT_REGION=UK and Ireland
OSSO_SWAP=/media/mmc2
OSSO_VERSION=RX-34+RX-44+RX-48_DIABLO_4.2008.36-5_PR_MR0
OSSO_PRODUCT_RELEASE_VERSION=4.2008.36-5
OSSO_PRODUCT_FULL_NAME=Nokia N810 Internet Tablet
OSSO_PRODUCT_RELEASE_NAME=OS 2008
OSSO_PRODUCT_SHORT_NAME=Nokia N810
OSSO_PRODUCT_HARDWARE=RX-44
OSSO_PRODUCT_KEYBOARD=English
OSSO_PRODUCT_WLAN_CHANNEL=ETSI/EU
OSSO_PRODUCT_RELEASE_FULL_NAME=Internet Tablet OS: maemo Linux based OS2008
OSSO_PRODUCT_NAME=N810

Could you post the above info from yours, as well as your control panel text
input settings?
Comment 17 Andrew Zabolotny (reporter) 2008-11-16 05:16:24 UTC
It worked for me with every ROM version I've got: so far chinook, diablo and
diablo-upgrade all worked fine, the only problem was with the browser (and only
with it).

product     RX-44
hw-build    0805
nolo        1.1.16

OSSO_VERSION=RX-34+RX-44+RX-48_DIABLO_4.2008.36-5_PR_MR0
OSSO_PRODUCT_HARDWARE=RX-44
OSSO_PRODUCT_FULL_NAME=Nokia N810 Internet Tablet
OSSO_PRODUCT_RELEASE_FULL_NAME=Internet Tablet OS: maemo Linux based OS2008
OSSO_PRODUCT_RELEASE_NAME=OS 2008
OSSO_PRODUCT_SHORT_NAME=Nokia N810
OSSO_PRODUCT_KEYBOARD=Russian-Latin
OSSO_SWAP=/media/mmc2
OSSO_PRODUCT_RELEASE_VERSION=4.2008.36-5
OSSO_PRODUCT_NAME=N810
OSSO_PRODUCT_WLAN_CHANNEL=ETSI/EU
OSSO_PRODUCT_REGION=Russia

I don't understand what you're expecting to happen when you choose the English
keyboard setting. Mine is Russian-Latin and that's exactly the languages it
switches between.

My guess is that if you switch language to Russian you'll be able to switch
between Cyrillic and Latin glyphs just like me. However, I don't quite
understand what you are expecting to happen when you choose the English
language setting.
Comment 18 Lucas Maneos 2008-11-16 18:10:40 UTC
$OSSO_PRODUCT_KEYBOARD actually refers to the physical keyboard variant, not to
the input method configuration settings.   I do have two languages set there. 
As I reported in bug 2501 my settings and goal is to have dual English and
Greek layouts, but even if I set both languages to eg Russian the keyboard only
produces latin characters in QWERTY layout.

It *sounds* like a software bug, but I'm starting to worry that it may be a
manufacturing defect in early units.  Does keyboard layout switching work for
anyone with a hw-build 0801 device?

Andre/Karsten: since it seems that this wasn't a duplicate of bug 2501 after
all, could you find out if that is also WONTFIX and reopen/adjust resolution
accordingly?