Steps to reproduce: 1. Launch Thunderbird and Accerciser. 2. Turn event monitoring on in Accerciser. 3. Copy and paste a large amount of text (e.g. see attached) into a new message in Thunderbird. Expected results: A single (or very, very few) object:text-changed:insert events would be emitted. Actual results: A bunch (perhaps one per line/paragraph? I didn't count) are emitted. 4. Select all of the text that was just pasted and press delete. Expected results: A single (or very, very few) object:text-changed:delete events would be emitted. Actual results: A bunch (perhaps one per line/paragraph? I didn't count) are emitted. These floods of events grind Orca to a complete halt (as reported by an Orca user). :-( I can confirm the problem, but I'm not entirely sure what we can do on our end to identify this condition reliably, stop the flood, and present something meaningful to the user. If there is anything you all can do on your end (e.g. emit only one event when the user pastes text and only one event when the user deletes text), it would be very much appreciated. Thanks!!

Thanks Joanmarie, does this also happen in FF -- can we recreate there somehow?

Seems that you can. I just tried pasting the sample text into this Additional Comments entry and saw the same thing. Question is: Can ya fix it? :-)

Sure, we could stop firing text-changed events. :) But seriously, yes we need to do some intelligent throttling. It might be hard to get the right balance of throttle vs fire enough of the right events.

I'm thinking about a timer hack solution to nsDocAccessible::FireTextChangeEventForText but I need to convince myself it is not a hack.

[self: set breakpoint in nsClipboard::GetData to see why this isn't atomic] Joanmarie, does this happen in non-FF cases (where text-changed events are supported)?

(In reply to comment #5) > Joanmarie, does this happen in non-FF cases (where text-changed events are > supported)? If by "non-FF cases" you mean "other apps on the GNOME desktop", Evolution floods us as well, but Evo is not exactly the paragon of accessibility. The rest of the apps I'd tried before filing this bug do not flood us.

Yep that's exactly what I meant thanks. I'm hoping there is something we can do here, but in the meantime I recommend throttling at your end too. Catch me on IRC for strategies if you like (I had to do this in GOK).

I did some Windows debugging of inserting text nodes into a textarea, and into a div. There is something odd about textarea but I need to investigate further. I have some shark data (from Mac) telling me there are child removals, causing us to invalidate our cache. Sorry if this sounds a bit scattered, but I want to pick up from here next time I look at this. I need to shark the text insertions into the div and cross check.

David, editor is trick thing :) Possibly we need to deep down into its sources.

Note I've been running various performance tests for different cases. For this bug we spend about 18% of our time in nsAccTextChangeEvent::nsAccTextChangeEvent with a call to GetText, which we don't need to do on Linux. So this bug might be mitigated somewhat if we move the GetText into our msaa wrapper (or ifdef out -- yuck). The real culprit, however, appears to be deeper as Alex says.

Yes, if GetText is not needed on Linux then we should move it to MSAA/IA2 part. But in general we should work on text events coalescence approach.

(In reply to comment #10) > Note I've been running various performance tests for different cases. For this > bug we spend about 18% of our time in > nsAccTextChangeEvent::nsAccTextChangeEvent with a call to GetText, which we > don't need to do on Linux. So this bug might be mitigated somewhat if we move > the GetText into our msaa wrapper (or ifdef out -- yuck). We ifdef'ed it out on bug 515685. This should at least make use fire them faster.

David, can you please retest this now that bug 240933 is fixed?

(In reply to comment #11) > Yes, if GetText is not needed on Linux then we should move it to MSAA/IA2 part. > But in general we should work on text events coalescence approach. The general bug for this is bug 392987. But I think this bug should be fixed by bug 570275. Joanie, could you please check this?

(In reply to comment #13) > David, can you please retest this now that bug 240933 is fixed? Sorry I didn't get around to this.

(In reply to comment #13) > can you please retest this now that bug 240933 is fixed? It's fixed by 240933 since the bug is about plain text insertion where we used to create br elements and fire text change event for them. If this bug was about rich text insertion then it would be bug 570275. Anyway we should be in good shape now for plain text and rich text both.