In web browsers such as Internet Explorer, when trying to find text in languages other than English, NVDA inserts odd things in Find dialog

[nvaccessAuto]

Reported by nvdakor on 2013-01-04 02:10
Hi,
In a webpage, when trying to find some text which is written in languages other than English, NVDA does not find it. Specifically, when opening Find dialog (CTRL+NvDA+F) and after switching input languages to ones other than English (for example, Korean), after typing some text, NvDA inserts odd things.

Steps to reproduce:

1. Go to a page that you know has non-English text (for example, ko.wikipedia.org, the Korean Wikipedia page).
2. after the page loads, try finding "Tools" heading (written in Korean). To do this, from top of the page, press CTRL+NvDA+F, then switch to Korean layout, then type "ehrn".
3. Before you press ENTER, review what you've typed. NVDA inserts some odd characters such as accents. Then when you press ENTER, NVDA does not find the text, since it inserted something else.

From tests I did, it appears NVDA Find dialog is not good at recognizing UTF-8 or Unicode chars. Thanks.

Blocking #3233

[nvaccessAuto]

Comment 1 by nvdakor on 2013-03-15 08:14
Hi,
Jamie says it is not WX. Ironically, the solution was to switch input language (the keyboard language itself, not input methods in a given lang) once NVDA starts. Then find function behaves normally. Strange, but it is a huge relief for now.

[nvaccessAuto]

Comment 2 by jteh on 2013-03-15 08:18
I can only reproduce this as follows:

1. Korean (Korea) - Microsoft IME is installed and set as the default input language.
2. Restart NVDA.
3. Try to type Korean in any NVDA editable text field; e.g. the browse mode Find dialog, the Python console, etc.

If Korean isn't the default language, the problem doesn't occur. As soon as I switch layouts, the problem goes away until NVDA is restarted.

So, if you have Korean set as the default language, you can work around this as follows:

1. Make sure you have at least one other layout installed.
2. Each time you start NVDA, switch to another layout and then back to Korean.

Debugging info:

• This is not a bug in wx. I wrote a simple wx app to test this.
• It isn't our keyboard hook, as I tried with it disabled.
• It doesn't occur in NVDA 2012.2, but does occur in NVDA 2012.3.

This unfortunately suggests it's probably something to do with our IME/TSF support.

[nvaccessAuto]

Comment 3 by jteh on 2013-03-15 08:20
For non-Koreans testing this, note that you need to hit right alt to switch to native input to be able to type Korean. You can try typing "ehrn". It should produce "도구".

[nvaccessAuto]

Comment 6 by mdcurran on 2013-05-28 02:05
This bug is caused by one or more calls to ImmLockIMC from imm32.dll. This call is made as part of the check to see if this is a valid IME message. If I remove these calls and just return true (to say its valid) everything works and the bug goes away.
ImmLockIMC is not documented at all for Windows Desktop, but only for Windows CE. I shall have to converse with Timothy Lee about this as this part was his code.
I would hope that we could just get away with checking that the window is not NULL and that is it, rather than using this rather lengthy, undocumented, and now buggy, code.

[nvaccessAuto]

Comment 7 by Michael Curran <mick@... on 2013-05-28 04:30
In [c7ba04d]:

NVDAHelper IME support: only call hasValidIMEContext for specific IME window messages, rather than for all window messages. Fixes #2909

This stops ImmLockIMC from being called for window messages such as wm_keydown which was causing some corruption of typed characters in certain situations such as when typing in NVDA's process with Korean or Japanese when it was the default IME.

Changes:
State: closed

[nvaccessAuto]

Comment 8 by jteh on 2013-05-28 07:07
Changes:
Milestone changed from None to 2013.1.1

[nvaccessAuto]

Comment 9 by nishimotz on 2013-05-28 12:06
Tested with snapshot 9166,4db91e5 on Windows 8 (64bit) Japanese.

The issue of #3233 does not occur any more with Microsoft Japanese IME.

However, after the composition session at 'Add Dictionary Entry', exiting NVDA (NVDA+Q) causes problem.

The ending music is not played and the NVDA processes are still alive.

As shown below, the log file does not end with "NVDA exit".

INFO - core.main (20:54:26):
Exiting
INFO - config.save (20:54:26):
Configuration saved

[nvaccessAuto]

Comment 10 by mdcurran on 2013-05-28 23:24
Just to be clear, did this happen before that commit or not?

[nvaccessAuto]

Comment 11 by nishimotz on 2013-05-28 23:41
Thank you. The process termination issue was also observed when I reported #3233 issue with 2013.1rc2.