Repeating of keyboard layout unappropriately in mozilla apps

[aleksey_s]

steps to reproduce

• navigate into firefox location bar
• press ctrl+shift to change keyboard layout

actual results

NVDA will announce and repeat new keyboard layout more than one time (up to ten)

expected results

NVDA must announce keyboard layout only one time

[pvagner]

Fixed in r3337

[aleksey_s]

Seems as NVDA again repeats keyboard layout several times when activating miranda-im contact list with ctrl+shift+a. NVDA 2009.1 speaks keyboard layout one time, but current trunk two times.

[aleksey_s]

Proposed implementation

[aleksey_s]

See attachment for proposed fix.

[mdcurran]

We used to have out-of-process code that filtered keyboard layout change notifications based on timing.
You are proposing that we add in timing code again, but this time in the hook in-process.
However, I would like to understand exactly why this double speaking is actually occuring.
The hook code currently saves off the lParam (hkl) and only notifies NVDA of the change if the lParam (hkl) has really changed.
Ither this code is just wrong, or static local variables are thread local (i.e. specific to a particular thread), or Miranda has more than one process who's keyboard layout has changed.

If there is more than one process, in-process time filtering will not help.
If static local variables are thread local, making the lastInputLangChange variable global should fix the double speaking, and therefore there'd be no need for time filtering.

So, your thoughts:
*Do you know if static local variables are thread-specific? I could not find information saying this is true, however it did warn against using them in a multi threaded application. If we want to follow the warning, we should probably make it global anyway.
*When you say the layout is spoken twice, do you know if hkl is identical for both notifications?
*What about the thread ID, is that also identical for both notifications?

[pvagner]

For me this double speaking does not happen with Miranda-IM.
One thing I can say for sure is that Miranda-IM for sure has multiple processes, even multiple modules.
There are some miranda-im plugins which are able to change the keyboard layouts according to your settings or according to the language filled in your chat opponent's profile.

[aleksey_s]

Replying to mdcurran:

We used to have out-of-process code that filtered keyboard layout change notifications based on timing.
You are proposing that we add in timing code again, but this time in the hook in-process.

I thought that there is no need to call cross process boundary just to test that this value isn't actually needed.

However, I would like to understand exactly why this double speaking is actually occuring.

I can only speculate about it. First of all, ctrl+shift is configured to be layout switch keystroke in my system. Note, that I press ctrl+shift+a to bring up miranda-im window. May be windows interprets it as layout change? Then miranda window has its own layout setting and NVDA reports it when miranda is coming to foreground.

*Do you know if static local variables are thread-specific? I could not find information saying this is true, however it did warn against using them in a multi threaded application. If we want to follow the warning, we should probably make it global anyway.

They are same as global variables just with limited scope. I suspect that warning assumes you will use global variables in non-safe way.

*When you say the layout is spoken twice, do you know if hkl is identical for both notifications?

Actually, two layout changes are spoken. With my patch only last is heart.

*What about the thread ID, is that also identical for both notifications?

I haven't checked this.

[aleksey_s]

Replying to pvagner:

One thing I can say for sure is that Miranda-IM for sure has multiple processes, even multiple modules.

Why do you think miranda has multiple processes? I can find only one in the task manager. Plugins are loaded as dynamic-link libraries and mapped into miranda32 process address space.

[aleksey_s]

Replying to mdcurran:

If there is more than one process, in-process time filtering will not help.

Sorry, thanks for the correction. I think we need add the time variable to the shared section for it be single for all in-process library instances.
Anyway, since this fixes double speaking for me, i think issue is not due the multiple processes.

[jteh]

Should be fixed again in r3586. Please close once verified.