NVDA jumps around in the Spotify desktop application

[nvaccessAuto]

Reported by parham on 2015-10-25 06:55
When using the Spotify desktop application, if you stay in the main HTML document, or keep navigating, the NVDA cursor will jump around onto an unknown control. Here is what I see in the log when this happens:

Developer info for navigator object:
name: None
role: ROLE_UNKNOWN
states: 
isFocusable: False
hasFocus: False
Python object: <NVDAObjects.IAccessible.IAccessible object at 0x05663210>
Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: None
value: None
appModule: <'appModuleHandler' (appName u'spotify', process ID 2220) at address 5369850>
appModule.productName: u'Spotify'
appModule.productVersion: u'1.0.16.104'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 12650122
windowClassName: u'Chrome_RenderWidgetHostHWND'
windowControlID: 123102184
windowStyle: 1445986304
windowThreadID: 4492
windowText: u'Chrome Legacy Window'
displayText: exception: 'NoneType' object is not iterable
IAccessibleObject: <POINTER(IAccessible) ptr=0x75e0d48 at 5571ee0>
IAccessibleChildID: -3123
IAccessible event parameters: windowHandle=12650122, objectID=-4, childID=-3123
IAccessible accName: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accRole: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accState: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accDescription: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accValue: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (10:14:36):
Developer info for navigator object:
name: None
role: ROLE_UNKNOWN
states: 
isFocusable: False
hasFocus: False
Python object: <NVDAObjects.IAccessible.IAccessible object at 0x0550A5B0>
Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: None
value: None
appModule: <'appModuleHandler' (appName u'spotify', process ID 2220) at address 5369850>
appModule.productName: u'Spotify'
appModule.productVersion: u'1.0.16.104'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 12650122
windowClassName: u'Chrome_RenderWidgetHostHWND'
windowControlID: 123102184
windowStyle: 1445986304
windowThreadID: 4492
windowText: u'Chrome Legacy Window'
displayText: exception: 'NoneType' object is not iterable
IAccessibleObject: <POINTER(IAccessible) ptr=0x75e1270 at 5491710>
IAccessibleChildID: -3903
IAccessible event parameters: windowHandle=12650122, objectID=-4, childID=-3903
IAccessible accName: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accRole: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accState: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accDescription: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accValue: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))

Is there a way to disregard this focus event so that navigation happens seamlessly in the main window?

[nvaccessAuto]

Comment 1 by driemer.riemer@... on 2015-11-02 08:42
Confirmed. Not sure how to tell nvda to ignore all focus events if they are ROLE_UNKNOWN. I did, however write an appModule that sets focus back to the original control, and suppresses speech, but it's sub-optimal. Telling nvda to ignore gainFocus for these unknown objects would be better.
Mik or jamie, how did this get fixed with firefox in the past? It used to happen in firefox some, although not as much as it does in spotify, but that was fixed.

[nvaccessAuto]

Comment 1 by driemer.riemer@... on 2015-11-02 08:42
Confirmed. Not sure how to tell nvda to ignore all focus events if they are ROLE_UNKNOWN. I did, however write an appModule that sets focus back to the original control, and suppresses speech, but it's sub-optimal. Telling nvda to ignore gainFocus for these unknown objects would be better.
Mik or jamie, how did this get fixed with firefox in the past? It used to happen in firefox some, although not as much as it does in spotify, but that was fixed.

[nvaccessAuto]

Comment 2 by jteh on 2015-11-02 09:11
This occurs because focus gets fired on an object which dies very quickly, so by the time NVDA queries it, it's already dead. Ideally, apps should never do this. This also happens if you use play.spotify.com in Chrome, but not in Firefox. There is no code in NVDA to block such events for Firefox, so Firefox seems to be filtering these out.

@driemer: You can stop focus hitting these by setting shouldAllowIAccessibleFocusEvent to False. I don't recommend this because focus hitting an unknown can be important; e.g. if the previous thing really did lose focus. Specifically for Spotify, it's probably safe because focus seems to still be on the previous thing, but we certainly couldn't do this for chromium overall.

[nvaccessAuto]

Comment 2 by jteh on 2015-11-02 09:11
This occurs because focus gets fired on an object which dies very quickly, so by the time NVDA queries it, it's already dead. Ideally, apps should never do this. This also happens if you use play.spotify.com in Chrome, but not in Firefox. There is no code in NVDA to block such events for Firefox, so Firefox seems to be filtering these out.

@driemer: You can stop focus hitting these by setting shouldAllowIAccessibleFocusEvent to False. I don't recommend this because focus hitting an unknown can be important; e.g. if the previous thing really did lose focus. Specifically for Spotify, it's probably safe because focus seems to still be on the previous thing, but we certainly couldn't do this for chromium overall.

[nvaccessAuto]

Comment 3 by driemer.riemer@... on 2015-11-05 04:23
Would some code that sets a time at gainFocus, and delays gaining focus for n milleseconds work? Then if loseFocus is called, we just nuke the timer and kil the object so it doesn't gain focus. Otherwise, after n milleseconds, the application would report being focused with nvda.

[nvaccessAuto]

Comment 3 by driemer.riemer@... on 2015-11-05 04:23
Would some code that sets a time at gainFocus, and delays gaining focus for n milleseconds work? Then if loseFocus is called, we just nuke the timer and kil the object so it doesn't gain focus. Otherwise, after n milleseconds, the application would report being focused with nvda.

[nvaccessAuto]

Comment 4 by jteh on 2015-11-05 04:31
We could do that, but i still think this is far too risky globally. To be clear, I'm happy to ignore unknown focus for Spotify specifically. I'm just not willing to do it for the whole of Chromium. That way, we limit the risk. Also, ideally, sites/apps just shouldn't do this, though as always, we may need to hack around this for specific cases.

[nvaccessAuto]

Comment 4 by jteh on 2015-11-05 04:31
We could do that, but i still think this is far too risky globally. To be clear, I'm happy to ignore unknown focus for Spotify specifically. I'm just not willing to do it for the whole of Chromium. That way, we limit the risk. Also, ideally, sites/apps just shouldn't do this, though as always, we may need to hack around this for specific cases.

[nvaccessAuto]

Comment 5 by parham (in reply to comment 4) on 2015-11-05 10:56
Replying to jteh:

[...] I'm happy to ignore unknown focus for Spotify specifically. I'm just not willing to do it for the whole of Chromium. That way, we limit the risk.

I agree 100%. I think it's better to start with Spotify, and if we figure out that other apps are doing something like this, think of a global solution then. There's no point creating a general hack around a problem that exists in only one application.

[nvaccessAuto]

Comment 5 by parham (in reply to comment 4) on 2015-11-05 10:56
Replying to jteh:

[...] I'm happy to ignore unknown focus for Spotify specifically. I'm just not willing to do it for the whole of Chromium. That way, we limit the risk.

I agree 100%. I think it's better to start with Spotify, and if we figure out that other apps are doing something like this, think of a global solution then. There's no point creating a general hack around a problem that exists in only one application.