NVDA causing Windows Live Messenger to exit on startup

[nvaccessAuto]

Reported by ManuelRamos on 2010-05-29 12:14
When opening Windows Live Messenger with Windows 7 and NVDA Trunk 3554, it is happening that WLM appears but, ater a fiew seconds it clooses without running Windows Live Messenger. We've been suggested to run WLM as administrators or to press Windows+t keys to open it. However, working around it will be much apreciated.

[nvaccessAuto]

Comment 1 by jteh on 2010-07-20 03:05
Confirmed. Additional info:

• Does not occur in Windows XP.
• Happens in both Windows 7 x86 and x64.
• Happens with nvdaHelper disabled, so this is not related to our in-process code.
• Happens with NVDA 2009.1.
• Happens with UIAHandler disabled.
• Does not happen with NVDA 0.6p3.2.
• Only happens if NVDA tries to access the application while it is first opening.
• There is no "crash" as such; postmortem debugger does not launch.

This one is really weird. I don't have a clue what's going on yet.
Changes:
Changed title from "NVDA losing focus in Windows Live Messenger" to "NVDA causing Windows Live Messenger to exit on startup"

[nvaccessAuto]

Comment 2 by jteh on 2010-07-20 07:02
This is quite bizarre.

I haven't been able to reproduce the problem while running in a debugger, probably because it doesn't get focus at the right time.

I've finally tracked the problem down to a nameChange event at startup from a window with a class name of "MSNHiddenWindowClass". It seems that NVDA can successfully instantiate the object, but if it does, Messenger silently exits. If I block the event before IAccessibleHandler.winEventToNVDAEvent() is called, everything works fine. I tried returning early in the IAccessible constructor if this window class is detected, but this doesn't help, so it must be occurring earlier than the NVDAObject construction. Disabling all !QueryService calls doesn't help.

[nvaccessAuto]

Comment 3 by jteh on 2010-07-20 07:11
Actually, further investigation reveals that the problem is the WM_NULL message that we send to the window to see if its alive in IAccessibleHandler.accessibleObjectFromEvent(). If I comment this out, the problem goes away. This (finally) explains why this didn't happen in 0.6p3.

The strange thing is that sending WM_NULL to the window once Messenger has fully started doesn't cause a problem.

[nvaccessAuto]

Comment 4 by jteh on 2010-07-21 07:16
Sending a custom window message instead of WM_NULL seems to solve this.

[nvaccessAuto]

Comment 5 by jteh on 2010-07-22 01:37
Work around implemented in c148e98.
Changes:
State: closed

[nvaccessAuto]

Comment 6 by jteh on 2010-10-28 06:19
This fix broke some Windows Security dialogs. It seems a generic fix just isn't going to work here. Therefore, implemented a more specific fix in 791d8b9.

[nvaccessAuto]

Comment 7 by EltonLopes (in reply to comment 6) on 2010-10-29 15:48
Hi James,

The problem with Windows Live Messenger 2009 return in Windows 7 with Windows Live Messenger 2009. This don't occur with NVDA 2010.2rc1.

Replying to jteh:

This fix broke some Windows Security dialogs. It seems a generic fix just isn't going to work here. Therefore, implemented a more specific fix in 791d8b9.

[nvaccessAuto]

Comment 8 by EltonLopes on 2010-10-29 15:51
Changes:
State: reopened

[nvaccessAuto]

Comment 9 by jteh on 2010-10-29 22:17
Oh dear. This works fine for me in Windows 7. The original fix cannot be used, as it severely breaks Windows Security dialogs.
Changes:
Milestone changed from 2010.2 to 2010.3

[nvaccessAuto]

Comment 10 by EltonLopes (in reply to comment 9) on 2010-10-31 22:50
I format my computer, and after it NVDA 2010.2 work perfectly with Windows Live Messenger 2009. I had the Windows 7 Ultimate x86 portuguese and I change to Windows 7 Professional x86.
In Windows 7 Professional, i tested disable the User Account Control, but all works the same.

Replying to jteh:

Oh dear. This works fine for me in Windows 7. The original fix cannot be used, as it severely breaks Windows Security dialogs.

[nvaccessAuto]

Comment 11 by jteh on 2010-11-09 00:07
Better fix in 54ed458.
Changes:
State: closed