Some edit boxes don't read their labels

[hozosch]

Sometimes, NVDA doesn't recognize labels of some edit boxes where a screen reader like Jaws hasn't got any problem.

Steps to reproduce:

1. Download and install the fast copy program. It is a good example of such labels.
2. Run it.
3. In the window, there are some edit boxes which NVDA doesn't read the labels of, but jaws does.

Expected behavior: NVDA reads the labels of these edit boxes correctly

Actual behavior: NVDA just says "Edit" without reading the label.

System configuration: doesn't matter, it's on any computer with a supported windows.

NVDA version: 2018.1.1

NVDA Installed or portable: installed

Other information:

Windows version: windows 7 proffessional 6.1.7601 service pack 1

Name and version of other software in use when reproducing the issue: fast copy

Other questions:

Does the issue still occur after restarting your PC?
Yes
Have you tried any other versions of NVDA?
It is with every version I used so far.

[LeonarddeR]

Could you please provide developer details of one of these edit boxes, i.e. by pressing nvda+f1 when the box has focus? This assumes that you haven't touched the setting for the navigator object to follow the focus.

[hozosch]

Yeah. This one is not from fast copy though, it's from a configuration dialog of a game. The label of this edit box is "First name", but NVDA doesn't read it.

INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (08:57:13.989):
Developer info for navigator object:
name: None
role: ROLE_EDITABLETEXT
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.Dynamic_IAccessibleEditWindowNVDAObject object at 0x05EF3750>
Python class mro: (<class 'NVDAObjects.Dynamic_IAccessibleEditWindowNVDAObject'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.edit.Edit'>, <class 'NVDAObjects.behaviors.EditableTextWithAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: (206, 132, 77, 29)
value: u'Karl'
appModule: <'appModuleHandler' (appName u'config', process ID 4304) at address 5f17f30>
appModule.productName: u'ConfigurationManager\x00\x00,\n\x01FileVersion\x00\x001.0'
appModule.productVersion: u'1.00\x00\x000\x0e\x01'
TextInfo: <class 'NVDAObjects.window.edit.EditTextInfo'>
windowHandle: 9307402
windowClassName: u'ThunderRT6TextBox'
windowControlID: 6
windowStyle: 1409351872
windowThreadID: 1632
windowText: u'Karl'
displayText: u'Karl'
IAccessibleObject: <POINTER(IAccessible) ptr=0x5ba890 at 5f4a300>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=9307402, objectID=-4, childID=0
IAccessible accName: None
IAccessible accRole: ROLE_SYSTEM_TEXT
IAccessible accState: STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048580)
IAccessible accDescription: None
IAccessible accValue: u'Karl'

[LeonarddeR]

The problem here is that the application itself doesn't expose the proper label to the text control. JAWS might be able to label this correctly, but this is based on JAWS specific heuristics that I've also seen failing due to wrong assumptions.

This could be solved by a label guessing system as proposed in #84, but then meant for desktop applications.