maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Input language switching does not work in browser entry fields|
|Product:||[Maemo Official Platform] Desktop platform||Reporter:||Andrew Zabolotny <anpaza>|
|Component:||Input method framework||Assignee:||Mohammad Anwari <mdamt>|
|Status:||RESOLVED WONTFIX||QA Contact:||input-method-framework-bugs|
|Priority:||Medium||CC:||andre_klapper, anpaza, karstenb, maemo, timeless|
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
there's an internal report for this...
Fixed in the internal revision.
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.
*** Bug 2501 has been marked as a duplicate of this bug. ***
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.
Also, confirming for obvious reasons.
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 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.
(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?
(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. :-/
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.
Reopening - this has not yet been fixed.
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."
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?
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.
(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?
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.
$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?