Reported by k_kolev1985 on 2010-05-25 09:20
Some applications crash while used with NVDA with its "mouse tracking" turned on
We, blind and visually impaired users in Bulgaria, have a speech synthesizer software, called "SpeechLab". This software has a small simple application called "SpeakText, witch in basics looks and serves for the same purpose as the TTS reader included with the eSpeak synthesizer. I've discovered some time ago that if I'm working with this "SpeakText" with NVDA, the app ("SpeakText") crashes. After some testing I found out that NVDA's "mouse tracking" feature is the cause for the crashing of "SpeakText". If the "mouse tracking" is turned on and I move the mouse cursor over the text edit area of "SpeakText", the application ("SpeakText") crashes, displaying the normal Windows error reporting window.
Recently, I've found out that the same problem occurs in the window of the "Synaptics TouchPad" software (this software is used to control the touchpads on laptops). This window is composed of the following elements: a treeview (settings categories) on the left side, buttons on the bottom, controls for the settings in the top right side, and a read-only text area below them (witch contains help information for the controls above). When I move the mouse cursor with NVDA's "mouse tracking" feature turned on over that read-only text area, The "Synaptics TouchPad" software crashes.
My guess is that both "SpeakText" and "Synaptics TouchPad" use a similar text edit area control, witch "doesn't like" NVDA's "mouse tracking" function. The only solution for now is to turn "mouse tracking" off while using those 2 applications.
Here are steps to reproduce the problem:
Some notes: The software product "SpeechLab" with witch comes "SpeakText" is free to use for us visually impaired and blind users in Bulgaria, but for others is not available as a shareware or a demo (as far as I know) - it has to be purchased in order to be used. So, I don't know if you will be able to test this issue with "SpeakText". I think that "SpeakText" is almost a standalone application (it only requires a .dll file witch is in the same program folder as "SpeakText" is). I think I could send only it to you privately for testing purposes - I suppose the developers of "SpeechLab" will not mind if I do so, since it is for testing purposes. O, and to say that this problem occurs with both NVDA 2010.1 and the latest snapshot.
Comment 2 by k_kolev1985 on 2011-09-18 10:40
I've tested this with main snapshot 4693 and the problem seams to be gone. I remember a recent change in revision main 4686 about a fix for some apps crashing - it seams that the specific change has also fixed the crashes in "SpeekText" and the Synaptics Pointing Device configuration utility, witch I point in this ticket. I'll try to see if it will fix the crashes of the NOD32 egui.exe process I reported in another ticket. No, it does not fix that issue - it seams that issue is related to something else.
Comment 3 by jteh on 2011-09-18 10:43
Closing as per comment:2. However, i doubt it was 1506eb0, as I'm pretty sure the code covered by that fix didn't exist when this ticket was filed.
Added labels: worksforme
Comment 4 by k_kolev1985 on 2011-09-27 08:00
I was using snapshot main 4693 and the problem was gone, although the function for reporting the text under the mouse cursor was broken in some applications (e.g. in the pane for the album art in Foobar2000's main window, the text in the app "SIS Contents", etc.). I last night installed snapshot main 4701 and the situation was reverted - the text was readable in those apps ("SIS Contents" and "Foobar2000"), but the problem of the crashing of "SpeakText" and the touchpad configuration utility window is back again - the moment I place the mouse cursor over the text edit area in those 2 apps, the crash occurs. It seams that a change between snaps 4693 and 4701 is causing this strange behaviour.
Removed labels: worksforme
Comment 5 by jteh on 2011-10-17 12:19
I was able to reproduce this in the Synaptics !TouchPad settings.
Technical: This occurs when we send EM_CHARFROMPOS to map a point to an offset. I think the reason is that this is a RICHEDIT control, so EM_CHARFROMPOS expects to be given a pointer. However, for some reason, the "RICHEDIT" window class has been mapped to window.edit.Edit, so we pass the points in hiword/loword form.
RICHEDIT was mapped to the Edit NVDAObject by Peter a very long time ago (c035cbb). Peter, do you recall by any chance why RICHEDIT was mapped to Edit instead of !RichEdit? Based on other stuff in that commit, I'd say it relates to Miranda somehow. This should be changed, but I'm guessing that this control misbehaves in some way if it was mapped like this in the first place.
Comment 6 by jteh on 2011-10-18 04:05
Fixed in c77621b. Hopefully, this doesn't break anything else.