Skip to content
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

Incorrect text being typed in some text fields with braille on #4291

Closed
nvaccessAuto opened this issue Jul 14, 2014 · 19 comments
Closed

Incorrect text being typed in some text fields with braille on #4291

nvaccessAuto opened this issue Jul 14, 2014 · 19 comments
Assignees
Milestone

Comments

@nvaccessAuto
Copy link

Reported by pitermach on 2014-07-14 11:29
If I have a braille display connected (HumanWare Brailliant BI in my case, although I spoke to a user of a baum display who also noticed this), in some rich text fields something causes Windows not to type the text in properly even though the keys seem to be registered fine. I know this is definitely happening in Wordpad, Skype, Tween, but notepad doesn't seem to be effected. I have attached 2 logs, one where I type in a text sentence without the display connected, and one where I do. In the second case I type it in multiple times and every time I get a slightly different result - once everything gets really mangled, another time it got typed fine and in another a space went missing. This was done in a blank wordpad file on Windows 8.1. The only way I found to avoid this is to type really slowly or disconnect the braille display when typing a lot, which is very inpractical.

@nvaccessAuto
Copy link
Author

Attachment without_braille.txt added by pitermach on 2014-07-14 11:30
Description:

@nvaccessAuto
Copy link
Author

Attachment with_braille.txt added by pitermach on 2014-07-14 11:31
Description:

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2014-07-15 01:57
What version of Windows are you using? We might know a way to fix this for Windows 7 and later, but not earlier.

A work around is to disable all font, color and style options, as well as reporting of links, in Document Formatting settings.

Technical: This occurs because the only way we can get formatting for RichEdit controls via window messages is to move the selection, but moving the selection while the user is typing obviously causes weirdness. We can use ITextDocument instead which doesn't have this issue, but ITextDocument is very slow on Windows XP (not sure about Vista), so we'd only want to do this in Windows 7 and later.

@nvaccessAuto
Copy link
Author

Comment 3 by pitermach on 2014-07-15 08:38
I'm using Windows 8.1. If you can fix it at least for Windows 7 and up it would definitely be a good thing and a nice start.

@nvaccessAuto
Copy link
Author

Comment 5 by jteh on 2015-07-15 09:27
@pitermach, do you have Announce formatting changes after the cursor enabled in NVDA's Document Formatting settings? I was only able to reproduce this problem with this option enabled.

@nvaccessAuto
Copy link
Author

Comment 6 by jteh on 2015-07-15 09:43
It'd be great if those affected can test the "next" branch snapshot for 16 July and report whether this is fixed there. @dkager, as noted in #3253, I suspect you're seeing this problem too.

@nvaccessAuto
Copy link
Author

Comment 7 by jteh on 2015-07-15 09:44
Bah. Specified the wrong ticket in the commit. It was incubated in b20bb59.

@nvaccessAuto
Copy link
Author

Comment 8 by dkager on 2015-07-15 15:23
Using NVDA next 12286,35a682a with eSpeak and the BC640 braille display, some document formatting reporting enabled, typing in WordPad:

  • With 'Announce formatting changes after the cursor' enabled I can easily reproduce this.
  • With 'Announce formatting changes after the cursor' disabled I can't reproduce the problem as easily. When typing quickly I occasionally get one letter appended to the end of the phrase instead of inserted in its proper position. For example, 'How are you?' could turn into 'How are ou?y'

If I then uncheck all options in the document formatting settings I can't reproduce this at all. This snapshot doesn't have the fix mentioned in comment:6, so will test again tomorrow.

@nvaccessAuto
Copy link
Author

Comment 9 by dkager on 2015-07-17 08:56
Tested with NVDA next 12289,171a430. I get the same results as with the snapshot for July 15. With 'Announce formatting changes after the cursor' enabled and all formatting options checked it's pretty much impossible to type coherently in WordPad. With fewer formatting options checked, or with 'Announce formatting changes after the cursor' disabled the results are much better but not completely accurate. Selecting 'No braille' also solves the problem completely on my machine.

@nvaccessAuto
Copy link
Author

Comment 10 by jteh on 2015-07-17 12:21
Ug. That's rather strange. What application(s) did you test this in? Can you please provide the dev info (NVDA+f1) for one of these controls?

@nvaccessAuto
Copy link
Author

Comment 11 by dkager on 2015-07-18 08:37
I'm using WordPad, see below. Typing quickly with NVDA next 12291,7c830b3 causes a CPU spike and also freezes the blinking braille cursor for a while. Sometimes bits of text are selected for no obvious reason. Maybe because I used the Shift-key while typing? I didn't use Backspace/Delete/arrow keys.

Dev info:

INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (10:24:57):
Developer info for navigator object:
name: u'Rich Text Window'
role: ROLE_EDITABLETEXT
states: STATE_MULTILINE, STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.Dynamic_IAccessibleRichEdit50WindowNVDAObject object at 0x05B27FF0>
Python class mro: (<class 'NVDAObjects.Dynamic_IAccessibleRichEdit50WindowNVDAObject'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.edit.RichEdit50'>, <class 'NVDAObjects.window.edit.RichEdit'>, <class 'NVDAObjects.window.edit.Edit'>, <class 'NVDAObjects.behaviors.EditableTextWithAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: (0, 135, 1440, 711)
value: u''
appModule: <'appModuleHandler' (appName u'wordpad', process ID 1428) at address 59f3410>
appModule.productName: u'Microsoft\xae Windows\xae Operating System'
appModule.productVersion: u'6.1.7600.16385'
TextInfo: <class 'NVDAObjects.window.edit.ITextDocumentTextInfo'>
windowHandle: 263260
windowClassName: u'RICHEDIT50W'
windowControlID: 59648
windowStyle: 1426096580
windowThreadID: 4840
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x6d2bd30 at 5a8cc60>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=263260, objectID=-4, childID=0
IAccessible accName: u'Rich Text Window'
IAccessible accRole: ROLE_SYSTEM_TEXT
IAccessible accState: STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048580)
IAccessible accDescription: None
IAccessible accValue: u''

@nvaccessAuto
Copy link
Author

Comment 12 by James Teh <jamie@... on 2015-07-23 06:25
In [e8a8325]:

Merge branch 't4291' into next

Incubates #4291.

Changes:
Added labels: incubating

@nvaccessAuto
Copy link
Author

Comment 13 by jteh on 2015-07-23 06:27
Ug. I missed something in my original attempt, so I can now certainly see why it would have had no visible effect. Hopefully, this attempt will work; it seems to for me.

Please try the "next" branch snapshot for 23 July, which should be up in about 3 hours.

@nvaccessAuto
Copy link
Author

Comment 14 by dkager (in reply to comment 12) on 2015-07-23 16:13
Did a quick test in WordPad again and today's next does indeed seem to fix the problems. I dare to say good job!

@nvaccessAuto
Copy link
Author

Comment 15 by msuch on 2015-07-23 16:48
It also fixes the probelm in Skype chat window where it also occured

@nvaccessAuto
Copy link
Author

Comment 16 by jteh on 2015-07-23 23:34
Thanks for the feedback. Barring any problems, I'll aim to get this into 2015.3.
Changes:
Milestone changed from None to 2015.3

@nvaccessAuto
Copy link
Author

Comment 17 by jteh on 2015-07-23 23:37
Note for merge to master: Squash commits. Remove mention of Announce formatting changes after the cursor from change entry, as the issue occurs even without this.

@nvaccessAuto
Copy link
Author

Comment 18 by leonarddr (in reply to comment 14) on 2015-07-28 13:14
Replying to dkager:

Did a quick test in WordPad again and today's next does indeed seem to fix the problems. I dare to say good job!

Same here, thanks for this fix!

@nvaccessAuto
Copy link
Author

Comment 19 by James Teh <jamie@... on 2015-07-31 03:16
In [89dd4b7]:

In Windows 7 and later, text is no longer garbled when typing in certain applications such as Wordpad and Skype with a braille display.

This is related to Rich Edit controls. It occurred because in order to get formatting information in these controls, we have to move the selection (and thus the cursor), which obviously causes problems if typed characters are arriving during this process.
To fix this, we can use ITextDocument. We previously disabled this due to poor performance, but it seems this is fixed in Windows 7 and later. Therefore, use ITextDocument in Windows 7 and later.
Also, the previous code for detecting links in ITextDocument still moved the selection. However, ITextDocument provides for another way to detect links which doesn't do this.
Fixes #4291.

Changes:
Removed labels: incubating
State: closed

@nvaccessAuto nvaccessAuto added this to the 2015.3 milestone Nov 10, 2015
jcsteh added a commit that referenced this issue Nov 23, 2015
…ain applications such as Wordpad and Skype with a braille display.

This is related to Rich Edit controls. It occurred because in order to get formatting information in these controls, we have to move the selection (and thus the cursor), which obviously causes problems if typed characters are arriving during this process.
To fix this, we can use ITextDocument. We previously disabled this due to poor performance, but it seems this is fixed in Windows 7 and later. Therefore, use ITextDocument in Windows 7 and later.
Also, the previous code for detecting links in ITextDocument still moved the selection. However, ITextDocument provides for another way to detect links which doesn't do this.
Fixes #4291.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants