Comment 1 by jteh on 2014-12-05 06:44
The question is whether it'd still take the same amount of time (or at least an unreasonably long time) if the string were split. If so, option 2 only works if you can cancel the first string before the second is sent. Right now, that certainly isn't possible, though it might (and that's a big might) be possible once speech is refactored.

I'm wondering whether we should just truncate the string and send the first n characters. We could maybe announce that the text was truncated. That kinda sucks, but it's far better than freezing or speaking nothing. It's also perfectly reasonable: sighted users have to scroll to see the rest of the text.

IMO, 10k really is quite insane. Even 1k is insane; a non-screen reader user can't read that much on one line.

Comment 2 by camlorn on 2014-12-05 19:10
yeah. I've seen this too, all be it rarely enough I've never bothered reporting. I think truncation is reasonable: the sighted user can't read a 1k line, but their eyes don't lock up and require restarting, either. The only problem is that NVDA may need to provide a method of actually scrolling in those cases. Maybe.

Hi,

This was brought up last night when someone sent a long string over Remote Support session that resulted in clients crashing.

Thanks.

Here is a test case. Wait 10 seconds or so and be prepared for your machine to become unusable. Tested with OneCore, Firefox and Chrome.

I notice this same issue with a long string of text or large content inserted into a div.

Have been experiencing NVDA simply not reading long lines anymore, when using gvim via a plugin that interfaces with gvim via OLE automation. This worked perfectly before this most recent version of NVDA. Have also experienced NVDA hanging when say the Windows console outputs a lot of text - this did not happen before. Unfortunately, reverting to an older NVDA does not solve this problem, but I'm unable to determine why this is the case. Another issue with the latest NVDA is that the error tree in the DBeaver database IDE, which is based on Eclipse, does not voice anymore. So, really unsure why things have gotten so terrible. I've tried disabling all add ons, tried different synts: problems persist.

`I'm having this same issue on NVDA 2021.3.3, I created some artificial test cases to reproduce but it occurs on real programs:

1. Open NVDA Python Console.

2. Paste this code and be prepared for the crash:

import speech;speech.speak("a" * 128 * 1024)

3. However, if you try speaking the string directly on the synthesizer (eSpeak in my case), it works:
   import synthDriverHandler;import time;synth = synthDriverHandler.getSynth();synth.speak("a" * 128 * 1024);time.sleep(2)

As a follow up, I think I found one of the problems. If you try to give the text to the speechDictHandler.processText function, it is taking a lot of time to complete. If this function is disabled (replacing it with a lambda for example), NVDA still lags, but returns in seconds.

It seems there is a particular regexp on the builtin.dic NVDA dictionary file is causing the problem. I'm not sure of which one but I tested removing the file from my installation and it spoke the long string.

Hi, I've just stumbled across this as well in #13432.

I'd like to request a prioritization of this issue, because of how it is much more severe than a normal crash. I had to restart the entire computer to get speech back. Its also something that an end user can't really do anything about e.g, the only way you know the file has the potential to crash NVDA is by looking at it first, which then causes said crash.

cc: @michaelDCurran

I'm going to close this and re-open #13432, since that is newer, uses the issue template and based on a real world use case, rather than python console input. Reviewing the comments here I note #4669 (comment) which seems to have been overlooked.