key echo problem

[nvaccessAuto]

Reported by Twinsen on 2012-06-05 19:00 None

[nvaccessAuto]

Attachment nvda bugs demo 1 added by Twinsen on 2012-06-05 19:58 Description:

[nvaccessAuto]

Attachment nvda.log added by surveyor on 2012-12-26 15:48 Description:

[nvaccessAuto]

Attachment log.txt added by a11cf0.vk on 2012-12-27 09:24 Description: Another log demonstrating this problem.

[nvaccessAuto]

Attachment nvda.2.log added by fatma.mehanna on 2013-02-06 00:43 Description:

[nvaccessAuto]

Comment 1 by Twinsen on 2012-06-05 20:32 Good day, Hi! I write this message from RUSSIA sorry for my bad level of english. List of bugs: 1) Im use the Internet Explorer 9. When I try edit text in form field on web page using Russian layout of keyboard , in the moment when I press buttons contained letter I hear (lisnnt)wrong letter of uncnown language.For example if a press ‘ц’-button (w) I dont hear the ‘ц’ sound but I hear sound like – awenlawt, but into the form field all ok – I see’ц’ In all cases in this text all keys (letters) of my keyboard work incorrectly. This situation repeated If I not into edet mode but only download the web page when system focus is in web page if I press any button not asociated with short keys this situation is repeat, I hear unknown language.This situation repeated If I work into WindowsLive mail client Windows Live Essentials in this case wrong languages is english. For example if i press ‘ц’-button (w) I dont hear the ‘ц’ sound but I hear sound like – english ‘o’,but ‘ц’ is dropped in the text field. Tell me how i can attach file *.nfo - msinfo32 this file size more than 256 kb?

[nvaccessAuto]

Comment 2 by MHameed on 2012-06-10 12:03 This happens for other langs too, such as arabic. There are several places that exibit this behaviour, most noticebly in ms products. @Fatima can you test and give us some examples, I remember this being reported on the arabic list. Thanks.

[nvaccessAuto]

Comment 3 by mohammed on 2012-06-10 12:58 just to clarify the description here:

with some keyboard layouts like Arabic, in some edit fields, when you insert a character, you hear English name of key, not actual inserted letter. when you review you find the correct letter has been inserted.

further tests will be done to provide examples. Changes: Changed title from "Wrong keys reading" to "key echo problem"

[nvaccessAuto]

Comment 4 by fatma.mehanna on 2012-06-10 20:52 the same problem occures in arabic in the previous example and also occures with windows live messenger 2011.

[nvaccessAuto]

Comment 5 by jteh on 2012-06-10 23:14 I doubt this is related to speech. It's more likely incorrect setting/detection of input locale in the application.

[nvaccessAuto]

Comment 6 by MHameed on 2012-07-13 12:00

2521 has been marked as a duplicate of this ticket.

[nvaccessAuto]

Comment 7 by beqa on 2012-07-13 12:06 yes, this is true for russian language too. please investigate this problem.

[nvaccessAuto]

Comment 9 by a11cf0.vk on 2012-12-19 12:49 Any progress on fixing this? This is a major internationalization problem and should be seriously investigated and fixed as quickly as posibal. This problem prevents international users from normally using many applications with NVDA. This happens not only in Internet Explorer, but randomly in many other programs.

[nvaccessAuto]

Comment 10 by surveyor on 2012-12-19 13:13 This is also valid for Turkish chars ş, ğ, and ı. There are many complains among Turkish NVDA users about this.

[nvaccessAuto]

Comment 12 by jteh on 2012-12-26 02:07 There is a lot of non-specific information here, so we don't have a chance of diagnosing this, let alone fixing it. For a start, all of the following questions must be thoroughly answered:

• Does this only affect speaking of typed characters?
• What applications does this occur in?
• What applications doesn't it occur in?
• What language is Windows set to use?
• What characters are affected: all or just some?
• When the problem occurs, is it always an English character that is spoken instead of the correct character or can it be another language?

[nvaccessAuto]

Comment 13 by a11cf0.vk on 2012-12-26 12:04 Hello. My Windows language is set to Russian and the system code page is CP1251. but it happens with any language that does not use ISO 8859-1 character set. Yes it happens only when NVDA trys to speak typed characters, not when deleting or just reading them with cursor keys. Standard ASCII characters are not effected. IT most frequently happens in Internet Explorer when entering text in editable fields in web-pages, but sometimes randomly happens in other applications like AkelPad. As stated in the other comments it also occurs in Windows Live programs. when this occurs NVDA speaks ISO 8859-1 characters instad of the intended ones. For example, instad of the Cyrillic leter "ч" nvda speaks "÷"And instad of the Cyrillic leter "и" NVDA speaks "è". For some risen, NVDA thinks that the typed characters should be converted to ISO 8859-1 before speaking them. sorry for my bad English.

[nvaccessAuto]

Comment 14 by jteh (in reply to comment 13) on 2012-12-26 13:03 Replying to a11cf0.vk:

IT most frequently happens in Internet Explorer when entering text in editable fields in web-pages, but sometimes randomly happens in other applications like AkelPad.

To clarify, for applications where this happens, does it always happen in that application; i.e. it never works correctly in that application? For example, does it always happen in Internet Explorer and AkelPad?

For some risen, NVDA thinks that the typed characters should be converted to ISO 8859-1 before speaking them.

Actually, NVDA isn't converting them. NVDA intercepts Unicode character messages, which are always supposed to be Unicode. I have no idea why the application is receiving incorrect Unicode character messages, nor do I know how the application gets the correct character itself.

[nvaccessAuto]

Comment 15 by a11cf0.vk on 2012-12-26 13:16 It always happens in Internet explorer, but in Akelpad it happens very rarely. Can this be related too strange Unicode handling implementation in Python 2?

[nvaccessAuto]

Comment 16 by surveyor (in reply to comment 14) on 2012-12-26 13:20 Replying to jteh:

To clarify, for applications where this happens, does it always happen in that application; i.e. it never works correctly in that application? For example, does it always happen in Internet Explorer and AkelPad?

According to my experiences and hearings, it always happens internet explorer, windows live messenger and live mail. Interestingly, the problem disappears if NVDA to be restarted after opening an edit area in these apps. For instance if you open a new email window in windows live mail and restart NVDA, chars are being read as they should be.

[nvaccessAuto]

Comment 17 by jteh on 2012-12-26 14:31 It looks like Microsoft's documentation of WM_CHAR is incorrect (or at least incomplete). WM_CHAR can be either Unicode or ANSI, depending on the type of the window. This means that when we get a WM_CHAR, if !IsWindowUnicode returns true, we need to convert the character from ANSI to Unicode based on the current keyboard layout.

I find it hard to believe that Internet Explorer or Windows Live Essentials would use ANSI windows, though, so I'm not sure if this will help. What versions of IE and WLE have this problem?

Apparently, ANSI WM_CHAR is delivered using the codepage of the KLID. This isn't necessarily the same as the thread locale, though I suspect display would break horribly if it wasn't. If it is, we can use CP_THREAD_ACP. if it isn't, we'll have to get the codepage from the KLID. This post describes how to get the codepage from the keyboard layout, but it uses the HKL, not the KLID. This post explains why this is wrong and we need to use the KLID, not the HKL. Arrrg! (Btw, this post describes how to get the KLID for the current layout.)

Other references:

• http://blogs.msdn.com/b/michkap/archive/2007/03/25/1945659.aspx
• http://blog.tavultesoft.com/2011/06/accepting-unicode-input-in-your-windows-application.html

[nvaccessAuto]

Comment 18 by jteh (in reply to comment 16) on 2012-12-26 14:41 Replying to surveyor:

Interestingly, the problem disappears if NVDA to be restarted after opening an edit area in these apps. For instance if you open a new email window in windows live mail and restart NVDA, chars are being read as they should be.

Ug. Can anyone else confirm this? If that is the case, my thoughts in comment:17 are wrong. In that case, I have absolutely no idea what is going on here. Restarting NVDA should have no effect on the typed characters that are spoken.

[nvaccessAuto]

Comment 19 by a11cf0.vk on 2012-12-26 14:46 Internet Explorer 9 definitely has this problem. I am not using Windows Live and cannot tele anything about it.

[nvaccessAuto]

Comment 20 by jteh on 2012-12-26 14:49 IE 9 is definitely Unicode, so that takes me back to not having any clue what is going on here. If anyone can figure this out, please do tell. Otherwise, I'm afraid we don't know how to fix this.

[nvaccessAuto]

Comment 21 by jteh on 2012-12-26 15:01 I just tested and I can't reproduce this. I installed the Russian keyboard layout and typed into an edit field in Internet Explorer. The Russian characters were correctly spoken, not ISO8859-1 characters.

[nvaccessAuto]

Comment 22 by surveyor (in reply to comment 21) on 2012-12-26 15:14 Replying to jteh:

I just tested and I can't reproduce this. I installed the Russian keyboard layout and typed into an edit field in Internet Explorer. The Russian characters were correctly spoken, not ISO8859-1 characters.

I've just tested and can reproduce. Snapshot main 5724, enabled speaking of characters while typing, Turkish q layout, IE 9, www.gmail.com. While entering turkish chars ğ, ü and ş in user name area, they are read incorrectly. it is normal while navigating and deleting. ğ is at the place of left bracket, and ı is at the place of i.

[nvaccessAuto]

Comment 23 by jteh on 2012-12-26 15:24 I can't reproduce with Turkish Q either. For me, again, these characters speak as they should when typed.

[nvaccessAuto]

Comment 24 by surveyor (in reply to comment 23) on 2012-12-26 15:46 Replying to jteh:

I can't reproduce with Turkish Q either. For me, again, these characters speak as they should when typed.

I'm not sure it is of use but you can find the log attached. I started IE, opened google and right the chars in question into the search box.

[nvaccessAuto]

Comment 25 by a11cf0.vk on 2012-12-26 15:48 I don't know, maybe this problem doesn't occur on systems with inglish locales.

[nvaccessAuto]

Comment 26 by surveyor (in reply to comment 25) on 2012-12-26 15:51 Replying to a11cf0.vk:

I don't know, maybe this problem doesn't occur on systems with inglish locales.

My machine is with windows 7 english.

[nvaccessAuto]

Comment 27 by a11cf0.vk on 2012-12-26 16:20 I tryed this on sevrel computers runing Windows 7 x64 sp1 Russian using latest snapshots of NVDA, and this problem occurs on all of them. I also tryed 32 and 64 bit versions of IE 9.

[nvaccessAuto]

Comment 28 by a11cf0.vk on 2012-12-27 07:48 I tested it with Internet Explorer again. 32-bit IE crashed after restarting NVDA, but 64-bit version of IE started to work normally after i restarted NVDA. When i open IE and type something in edit fields Nvda still reports the typed characters incorrectly, but when i restart nvda without closing IE, NVDA starts to read typed characters normally. Now the 64-bit version of IE also crashes when restarting NVDA.

[nvaccessAuto]

Comment 29 by jteh on 2012-12-27 08:27 Mick pointed out that we use !SetWindowsHookExW, so we should receive Unicode messages even in an ANSI app. Unfortunately, without being able to reproduce it, I can't debug any further.

[nvaccessAuto]

Comment 30 by mohammed on 2012-12-27 09:21 very interesting results: on a windows 7 64 bit English,do the following

1. add the Arabic keyboard layout.
2. change system locale to Arabic Jordan.
3. after restarting switch to vocalizer Arabic (I assume you do have it jamie?).
4. go to www.google.com in internet explorer 9
5. in the search field type some arabic characters. notice how it doesn't echo them back at all. 5, backspace to delete characters, notice how they are echoed back correctly.

now if you repeat the same steps with system locale set to English, this will not be reproduced.

[nvaccessAuto]

Comment 31 by jteh on 2012-12-27 09:59 @surveyor, what do you have your system locale set to? I wonder if changing the system locale is the key.

[nvaccessAuto]

Comment 32 by k_kolev1985 on 2012-12-27 12:01 Hello,

Strangely enough, I don't have such problems in Internet Explorer (v9.0). I'm using Windows 7 Ultimate SP1 32-bit with bulgarian locale settings. Internet Explorer itself is also in bulgarian. When I type cyrillic characters in the Google's search field (in www.google.com) for example, I hear the correct names of the characters.

But I have this problem in the edit fields of an application called "WhereIsIt" (v3.97.612), where I hear the ISO characters names when typing cyrillic characters in those edit fields. I don't know if the version of "WhereIsIt" witch I use is Unicode-based or not.

[nvaccessAuto]

Comment 33 by a11cf0.vk on 2012-12-27 12:23 On a Russian 64-bit system, changing the locale too English is not helpful for me When i start IE before starting NVDA, start NVDA, and than try to enter Cyrillic chars, everything is spoken correctly.

[nvaccessAuto]

Comment 34 by surveyor (in reply to comment 31) on 2012-12-28 08:00 Replying to jteh:

@surveyor, what do you have your system locale set to? I wonder if changing the system locale is the key.

I've tested it personally with two machines. one with Windows 7 32bit English, NVDA English, IE English. The other with windows 7 64bit and all are Turkish. As I wrote before, if NVDA starts or restarts after openning IE, live mail compose message or live messenger messaging window, chars are read as they should be, regardless of windows or NVDA locale. Actually, I knew about this strange thing for a long time, but still don't have any idea how to help developpers to reproduce this.

[nvaccessAuto]

Comment 35 by mohammed on 2012-12-28 08:25 hi.

that's right. if you restart NVDA while internet explorer is open, keys are echoed back correctly, even though system locale is set to Arabic.

I am afraid this complicates diagnoses even further.

[nvaccessAuto]

Comment 36 by a11cf0.vk on 2012-12-28 10:06 This also regularly happens in the latest beta version of Notepad2 5.0.26-beta4, but not in the final 4.2.25 version.

[nvaccessAuto]

Comment 37 by jteh on 2013-01-08 09:28 I can't reproduce this in IE 9 on Win 7 64-bit even if I change my system locale. Arrrg!

When this occurs, does changing the keyboard layout (by pressing alt+shift) and then changing it back solve it?

For those who have this problem in IE 9, please do the following:

1. Reproduce the problem.
2. Immediately press NVDA+control+z to open the NVDA Python Console.
3. Copy and paste the following line:

 import ctypes; ctypes.windll.user32.IsWindowUnicode(focus.windowHandle)

1. Press enter.
2. Report here whether NVDA says 1 or 0. I'm pretty sure it should say 1, but i want to be certain.

[nvaccessAuto]

Comment 38 by a11cf0.vk (in reply to comment 37) on 2013-01-08 09:42 Replying to jteh:

I can't reproduce this in IE 9 on Win 7 64-bit even if I change my system locale. Arrrg!

When this occurs, does changing the keyboard layout (by pressing alt+shift) and then changing it back solve it?

For those who have this problem in IE 9, please do the following:

1. Reproduce the problem.
2. Immediately press NVDA+control+z to open the NVDA Python Console.

3. Copy and paste the following line:

   import ctypes; ctypes.windll.user32.IsWindowUnicode(focus.windowHandle)

4. Press enter.
5. Report here whether NVDA says 1 or 0.

I'm pretty sure it should say 1, but i want to be certain.

Changing keyboard layout and than switching it back does not solve this problem. NVDA says 1.

[nvaccessAuto]

Comment 39 by k_kolev1985 on 2013-01-08 10:34 Hello,

As I said before, I don't have this problem under IE9. But I do have it with "WhereIsIt". Changing the keyboard layout doesn't help. And NVDA reports "1" after executing the command in the NVDA Python console.

[nvaccessAuto]

Comment 40 by mdcurran on 2013-02-02 02:29 Okay, I'm now able to reproduce this in IE9 on Win7 using the Turkish Q layout. Starting Internet Explorer with NVDA already running, if I type ş NVDA is notified that a Þ is typed (which is incorrect). If I then restart NVDA, NVDA correctly announces ş.

I can also reproduce this with the US - International layout, by trying to type ‘ or ’.

It seems that if NVDa hooks wh_getmessage when Internet Explorer starts, the wm_char messages NVDA's hook gets always contains an ANSI character (between 0 and 255) using the codepage of the selected layout. I.e. typing in turkish gives back wm_char messages with characters in latin5.

Hooking wh_getmessage after Internet Explorer has already started, correctly results in wm_char messages with actual UTF-16 characters.

The only way I can currently think of to get around this is to API hook GetMessage and PeekMessage (both A and W variants) and detect wm_char messages coming out. For the A variant, use multibyteToWideChar to convert to unicode using the currently selected codepage.

No idea why the Windows hooks are doing these odd conversions.

[nvaccessAuto]

Comment 41 by mdcurran on 2013-02-05 00:17 Hopefully fixed in 3fd28869e84654b92ae23ac45922674ab034e981. My tests show its fixed in IE9 on Win7, but there may be other places that need to be tested. Please provide feedback as to whether its been fixed in your specific situations.

[nvaccessAuto]

Comment 42 by jteh on 2013-02-05 02:23 Changes: Milestone changed from None to 2013.1

[nvaccessAuto]

Comment 43 by a11cf0.vk on 2013-02-05 12:12 I tested NVDA main 5826 with IE 9 32 and 64-bit and with Notepad2 5.0.26-beta4. All typed characters are spoken correctly. The bug is fixed now.

[nvaccessAuto]

Comment 44 by k_kolev1985 on 2013-02-05 12:57 I've also tested NVDA snapshot main r2826 and can confirm that the problem is fixed for "WhereIsIt" as well. Thanks!

[nvaccessAuto]

Comment 45 by surveyor (in reply to comment 41) on 2013-02-05 13:17 Replying to mdcurran:

Hopefully fixed in 3fd28869e84654b92ae23ac45922674ab034e981. My tests show its fixed in IE9 on Win7, but there may be other places that need to be tested.

Please provide feedback as to whether its been fixed in your specific situations.

I can confirm that it's fixed for the cases I've previously described. Thanks!

[nvaccessAuto]

Comment 46 by mdcurran on 2013-02-05 16:30 Changes: State: closed

[nvaccessAuto]

Comment 47 by a11cf0.vk on 2013-02-05 17:35 Thanks for fixing this.

[nvaccessAuto]

Comment 48 by fatma.mehanna on 2013-02-06 00:41 hi, i also confirm that the problem has been already fixed for the arabic users, but another problem unfortunately occured. I don't know if it is related to fixing this bug, but it happened when i used snapshot 5826. the problem is when i use the flat review on an arabic word, the arabic word/filename is being read in a reversed way. this wasn't happened before. steps to reproduce: 1 use the arrowkeys/the quick navigation letters to hilite a filename with arabic characters. 2 press nvda+nompad 7 to use the flat review. results: nvda reads the hilighted filename in a reversed way. of course i know there is a ticket for reversing the arabic words, but now, reversing words started to appear in other places that we never faced this problem in. I don't know if it is a separate problem, or it should be addressed here. i use windows xp, so i don't use ie9, but a feedback from our arabic users reported that they face the same problem in windows 7. this is a log file with the problem.