New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA stops working after using Windows Media Player #5467

Closed
nvaccessAuto opened this Issue Nov 6, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@nvaccessAuto

nvaccessAuto commented Nov 6, 2015

Reported by a11cf0.vk on 2015-11-06 16:40
Hello.
NVDA often stops working after using Windows Media Player 12 on Windows 7.

STR:

  1. Open any media file with WMP
  2. Tab to any playback control and interact with it
  3. Close the player.

After closing the player NVDA starts to give errors on every movement of the focus and completely stops speaking. After this, the only way to continue working is to restart NVDA.
This happens almost always, but sometimes it doesn't. Also, this generally doesn't happen when there was no interaction with the player's controls.

Here's an extract from the log.

ERROR - eventHandler.executeEvent (18:26:08):
error executing event: gainFocus on <NVDAObjects.IAccessible.IAccessible object at 0x05DE6790> with extra args of {}
Traceback (most recent call last):
File "eventHandler.pyc", line 138, in executeEvent
File "eventHandler.pyc", line 151, in doPreGainFocus
File "api.pyc", line 134, in setFocusObject
File "appModuleHandler.pyc", line 240, in handleAppSwitch
AttributeError: 'AppModule' object has no attribute '_configProfileTrigger'

I'm using the latest next snapshot of NVDA on Windows 7 x64. I also tried both 32 and 64-bit versions of WMP with same results.
Thanks.

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Nov 6, 2015

Comment 1 by jteh on 2015-11-06 21:35
For which applications, if any, do you have application specific configuration profiles?

nvaccessAuto commented Nov 6, 2015

Comment 1 by jteh on 2015-11-06 21:35
For which applications, if any, do you have application specific configuration profiles?

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Nov 7, 2015

Comment 2 by a11cf0.vk (in reply to comment 1) on 2015-11-07 08:08
Replying to jteh:

For which applications, if any, do you have application specific configuration profiles?

I don't have any application-specific profiles.

nvaccessAuto commented Nov 7, 2015

Comment 2 by a11cf0.vk (in reply to comment 1) on 2015-11-07 08:08
Replying to jteh:

For which applications, if any, do you have application specific configuration profiles?

I don't have any application-specific profiles.

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer Aug 12, 2016

Collaborator

I have figured out how to reproduce this bug.

  1. Open a media file in windows media player.
  2. Go to a slider, such as the seek or volume slider.
  3. press alt+f4, and NVDA will constantly play the error sound and be dead.
Collaborator

derekriemer commented Aug 12, 2016

I have figured out how to reproduce this bug.

  1. Open a media file in windows media player.
  2. Go to a slider, such as the seek or volume slider.
  3. press alt+f4, and NVDA will constantly play the error sound and be dead.
@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Jan 19, 2017

Contributor

P1 because this completely breaks NVDA once it happens and it seems like a pretty serious bug in the config profile trigger code.

Contributor

jcsteh commented Jan 19, 2017

P1 because this completely breaks NVDA once it happens and it seems like a pretty serious bug in the config profile trigger code.

@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran Jan 23, 2017

Contributor

Technical:
This is caused by the following chain of events:

  1. As media Player exits, there is a foreground event on the main window. However, this window dies somewhere between the winEvent being filtered, and the appModule being created for the resulting NVDAObject. This causes focus to be set on this NVDAObject representing a dead window, and an appModule with a processID of 0.
  2. When setting the focus object, ancestors for both the new and old focus objects are walked and compared to see where they differ. It is found that this new focus object (for the dead media player main window) matches one of the old ancestors, thus the new ancestor list generated contains all common ancestors, including the old ancestor that matches this focus object. But as the old ancestor was created a long time before (when the media player main window was alive) the appModule it got was made from a valid processID. Therefore, although these two objects correctly match, the old copy has a valid appModule, but the new copy has an invalid appModule.
  3. The newAppModule list (passed to handleAppSwitch) is made from the ancestors before the new focus (final ancestor) is stripped off. Thus newAppModules list contains the valid appModule, not the invalid appModule.
  4. later on, for the next focus event, an oldAppModules list (for passing to handleAppSwitch) is generated from the old focus object and its ancestors. Therefore, oldAppModules list contains the invalid appModule, not the valid one. As this appModule never appeared in newAppModules list, it was never initialized for config profile switching.

The most important fix here is to ensure that newAppModules list contains the correct appModule for the focus object. I.e. generate newAppModules after the last ancestor is stripped, but then append the focus object's appModule to newAppModules.

As to why we see this bug on this particular slider... I have no darn idea.
We may also consider raising clear errors if an appModule is ever created with a processID of 0. Interestingly, this is actually happening quite a lot for foreground events after task switching in Windows 10. Again, because a window dies after winEvent filtering but before the appModule is created.

Contributor

michaelDCurran commented Jan 23, 2017

Technical:
This is caused by the following chain of events:

  1. As media Player exits, there is a foreground event on the main window. However, this window dies somewhere between the winEvent being filtered, and the appModule being created for the resulting NVDAObject. This causes focus to be set on this NVDAObject representing a dead window, and an appModule with a processID of 0.
  2. When setting the focus object, ancestors for both the new and old focus objects are walked and compared to see where they differ. It is found that this new focus object (for the dead media player main window) matches one of the old ancestors, thus the new ancestor list generated contains all common ancestors, including the old ancestor that matches this focus object. But as the old ancestor was created a long time before (when the media player main window was alive) the appModule it got was made from a valid processID. Therefore, although these two objects correctly match, the old copy has a valid appModule, but the new copy has an invalid appModule.
  3. The newAppModule list (passed to handleAppSwitch) is made from the ancestors before the new focus (final ancestor) is stripped off. Thus newAppModules list contains the valid appModule, not the invalid appModule.
  4. later on, for the next focus event, an oldAppModules list (for passing to handleAppSwitch) is generated from the old focus object and its ancestors. Therefore, oldAppModules list contains the invalid appModule, not the valid one. As this appModule never appeared in newAppModules list, it was never initialized for config profile switching.

The most important fix here is to ensure that newAppModules list contains the correct appModule for the focus object. I.e. generate newAppModules after the last ancestor is stripped, but then append the focus object's appModule to newAppModules.

As to why we see this bug on this particular slider... I have no darn idea.
We may also consider raising clear errors if an appModule is ever created with a processID of 0. Interestingly, this is actually happening quite a lot for foreground events after task switching in Windows 10. Again, because a window dies after winEvent filtering but before the appModule is created.

michaelDCurran added a commit that referenced this issue Jan 24, 2017

NVDA no longer becomes unusable after exiting Windows Media Player wh…
…ile focused on a slider control.

api.setFocusObject: ensure that the newAppModules list passed to appModuleHandler.handleAppSwitch contains the appModule for the new focus, rather than only the appmodule for an original focus ancestor that happened to match the new focus.
Fixes #5467.

@nvaccessAuto nvaccessAuto added this to the 2017.1 milestone Feb 8, 2017

michaelDCurran added a commit that referenced this issue Feb 8, 2017

NVDA no longer becomes unusable after exiting Windows Media Player wh…
…ile focused on a slider control. (#6787)

api.setFocusObject: ensure that the newAppModules list passed to appModuleHandler.handleAppSwitch contains the appModule for the new focus, rather than only the appmodule for an original focus ancestor that happened to match the new focus.
Fixes #5467.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment