Attachment nvda.log added by ianr on 2012-10-29 20:05
Description:

Comment 1 by jteh on 2012-10-30 00:02
Can you please test with NVDA 2012.2.1? I want to know whether this is a regression.

If NVDA is displaying the same line in braille a lot, it suggests that VS is flooding NVDA with some event. However, I'm not sure what event.

Comment 2 by ianr on 2012-10-30 01:58
Yes, NVDA 2012.2.1 is what I usually use.

While it does sometimes lag in Visual Studio it is not as often as with NVDA 2012.3 beta 3.

For instance today after getting the problem with beta 3 I switched back to using 2012.2.1 for the rest of the day with far less problems.

So there is a definite difference and this seems to be a regression.

I just tested again with beta 3 and when in a C# file I didn't have the problem but as soon as I used control + tab to switch to a C++ file it started happening again.

Comment 3 by jteh on 2012-10-30 02:00
I guess this could be due to tooltip events (which we didn't listen to in 2012.2.1). However, we really do need to listen to those for Windows 8. I guess we could make this Windows 8 specific for now, though this obviously won't solve the problem for Windows 8 users.

Comment 4 by ianr on 2012-10-30 02:26
Yes, unless you can specifically unsubscribe to tooltip events for Visual Studio.

First we should verify that it is tooltip events causing the problem.

If you can provide a build that has tooltip events disabled or that at least logs when they are occurring I'd be glad to test with it.

Or even if you can provide links to existing snapshots, one before tooltip listening was implemented and one after I could test with those.

I personally am not using Windows 8, but that does not help those who are.

Comment 5 by jteh on 2012-10-30 03:47
Please try the following:

1. Press NVDA+control+z to open the NVDA Python console.
2. Copy and paste the following line:

 import UIAHandler; UIAHandler.handler.clientObject.RemoveAutomationEventHandler(UIAHandler.UIA_ToolTipOpenedEventId, UIAHandler.handler.rootElement, UIAHandler.handler)

1. Press enter.
   Does this revert to NVDA 2012.2.1 behaviour for this case?

Comment 6 by ianr on 2012-10-30 20:46
I tried your suggestion but it does not fix the problem.

In my email the lines were different they had and around them and additional indenting.
I copied from the browser and pasted those.
The console returned 0. I assume that is expected.

If you have another idea I'm up for it. Or if there is an easy way for me to download any of the old snapshots I could do a sort of binary search using the snapshots until we find out about where the first snapshot with the problem occurred.

Comment 7 by jteh (in reply to comment 6) on 2012-10-31 01:04
Replying to ianr:

I tried your suggestion but it does not fix the problem.

Hmm. Same thing, but try with the line:

import UIAHandler; UIAHandler.handler.clientObject.RemoveAutomationEventHandler(UIAHandler.UIA_MenuOpenedEventId, UIAHandler.handler.rootElement, UIAHandler.handler)

In my email the lines were different they had and around them and additional indenting.

They are WikiFormatting markup. It's best to copy from the browser unless you know how to interpret them.

The console returned 0. I assume that is expected.

Yes.

Or if there is an easy way for me to download any of the old snapshots

Afraid not. We don't have the disk space on our servers to keep them around, unfortunately.

Comment 8 by ianr on 2012-11-01 18:06
Sorry to report it is still a problem with the new line you gave me.

Comment 9 by ianr on 2012-11-01 18:17
It is odd to me that only the braille is repeated and not the speech.
Is there an event that Visual Studio can trigger that updates only the braille?

Have there been any driver updates to the BAUM Brailliant 80 specifically?

I tested again with braille disabled and the problem is definitely gone even without running anything in the python console.

Comment 10 by jteh on 2012-11-01 22:00
Braille gets updated in response to several events that don't necessarily affect speech. Without further debugging locally, I can't tell which event is the culprit.

Comment 11 by mdcurran on 2012-11-03 00:48
Fixed in f1b50b8. WpfTextView controls (as used for the VS 10 editor) Fire name and state changes once per second, and also fire them for each call to IUIAutomationTextRange::GetAttributeValue, which caused NVDA's braille code to reenter many times. Currently now NVDA will just ignore all name and state changes on WpfTextView controls. This should be solved better in the future. This certainly stops the lag for me when arrowing over file names in the output window, and also allows the braille cursor to flash properly in all these controls.
More technical info:
NVDA 2012.2.1 also called IUIAutomationTextRange::GetAttributeValue but didn't have the lag. I can only track it down to the fact that in NVDA 2012.2.1 there was an extra call to IUIAutomationTextRange::expandToEnclosingUnit (character) (but in that case it was character before that anyway). I think though that that is just another oddity in relation to the over all bug with that control rather than something we're expected to do.
Changes:
State: closed

Comment 12 by ianr on 2012-11-03 19:15
I've tested with the snapshot you mentioned and it's definitely fixed.
Visual Studio feels considerably more responsive, perhaps even more than 2012.2.1.

Thank you very much!

Comment 13 by jteh on 2012-11-04 10:03
Changes:
Milestone changed from None to 2012.3