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's responsiveness and stability are affected by applications that stop responding #1408
Comments
Attachment NonResponder.exe added by ianr on 2011-03-09 00:58 |
Comment 1 by jteh on 2011-03-09 01:19 #1189 also addresses this issue, though it was originally specific to applications which freeze on exit, so I've closed it as a duplicate. |
Comment 2 by ianr on 2011-03-10 16:51 I tested with JAWS and it stays responsive when I cause the test application to stop responding so they have obviously found a way to work around this. If you are willing to take some time to document the experimental code you were working on I am interested in looking at it. I believe that fixing this problem would make NVDA feel much more stable but I realize that overriding low level windows API functions is not something to be undertaken lightly. None the less, I am still interested in seeing the experimental code and gaining a better understanding of how this could be solved. |
Comment 3 by jteh (in reply to comment 2) on 2011-03-10 21:43
There are times when the system is just legitimately slow due to load. If we reduce this, the problem is that it might kill off some legitimate calls. This causes real problems in, for example, MS Office, where if we fail to retrieve the native object model, everything falls over rather nastily.
Interesting. I've certainly seen cases where other screen readers freeze as well due to unresponsive applications (the application error dialog is a case that often seems to freeze), but each case is slightly different. Note that most screen readers work more in-process than NVDA does, which means that their performance in other processes is sometimes unaffected by a freeze in one process. This may explain why JAWS seems to cope better here. This is an architectural difference; NVDA is primarily out-of-process and bringing the entire program in-process is not an option.
There isn't really much to document. Basically, I hooked !SendMessage and !SendMessageTimeout for oleacc and UIAutomationCore. For !SendMessage, i redirect the call to !SendMessageTimeout and enforce a 1 second timeout. For !SendMessageTimeout, I ensure that the timeout can never be more than 2 seconds, which I do because Windows accessibility uses ridiculous timeouts like 20 seconds.
The code is in this branch: http://bzr.nvaccess.org/nvda/lessFreezing2 |
Comment 4 by jteh on 2011-03-10 21:50 |
Comment 5 by jteh on 2011-03-11 00:12 |
Comment 6 by jteh on 2011-04-02 10:57 |
Comment by jteh on 2011-05-26 22:19 |
Comment 8 by jteh on 2011-06-01 21:48 |
Comment 10 by jteh on 2011-06-09 07:18 |
Comment 11 by jteh on 2011-08-29 00:23 As of now, snapshots are being generated for lessFreezing2. Anyone experiencing NVDA freezes in various situations should try lessFreezing2 snapshots and report. However, be aware that this is experimental code; the usual warnings apply. |
Comment 13 by dwillemv on 2011-08-29 04:05 |
Comment 14 by jteh on 2011-08-29 04:21 |
Comment 15 by jteh on 2011-09-05 10:34 |
Comment 16 by jteh on 2011-09-27 00:27 |
Reported by ianr on 2011-03-09 00:57
I have noticed that when applications stop responding for a period of time it usually causes nvda to stop reading and stop reacting to nvda keyboard shortcuts.
I have noticed this with notepad, EdSharp, Internet Explorer, and Visual Studio recently but I believe the problem would manifest itself similarly in any program that stops responding.
I have made a small application to help test this scenario.
I am attaching it to the ticket.
The application has a text box and a button, enter the number of seconds you would like the program to stop responding for and press the button, then you can see how nvda responds to it.
When the application begins responding again it will use the default SAPI voice on your machine to let you know.
In my personal testing I have noticed many different results, I am outlining them here:
1 NVDA stops responding for the entire time that the test application is not responding
2 NVDA becomes unresponsive for a few seconds and then becomes responsive again.
3 NVDA will continue reading items but ignores my key presses in the sense that it will not interrupt speech as it normally does when you press a key
4 NVDA continues to output to my braille display correctly though speech has stopped
5 NVDA stays responsive
The test application requires .NET Framework 4 client profile to be installed, I believe this can be obtained through windows updates.
I hope the application can be helpful in testing and fixing this issue.
Blocking #1528
The text was updated successfully, but these errors were encountered: