…s.UIA.XamlEditableText when removin editable field support from emoji panel. Re nvaccess#15836.

Regression introduced with nvaccess#14888: Windows 11 emoji panel items are not annonced when pressing arrow keys as XAML editable text overlay class is used to mark emoji search field. Therefore, remove the newly introduced XAML editable text class from overlay class chooser.

…s.UIA.XamlEditableText when removin editable field support from emoji panel. Re #15836. (#15837)

Regression introduced with #14888: Windows 11 emoji panel items are not announced when pressing arrow keys as XAML editable text overlay class is used to mark emoji search field. Therefore, remove the newly introduced XAML editable text class from overlay class chooser.

Closes #15836

Summary of the issue:
Windows 11 emoji panel items are not annonced when using arrow keys to navigate the emoji panel.

Description of user facing changes
Emoji panel items are once again announced when using the arrow keys to navigate Windows 11 emoji panel.

Description of development approach
In modern keyboard/emoji panel app modue, replace regular editable text with NVDAObjects.UIA.XamlEditableText when detecting and removing edit field commands form emoji search field.

follow up of #14888

Summary of the issue:
During development of #14888, it was observed that XAML edit fields tend to fire text change events before the caret position is changed, resulting in wrong text reporting. After using Visual Studio, I discovered that the same issue applies to the text controls in Visual Studio, notably WPF.

Description of user facing changes
In Visual Studio, the caret position is no longer sometimes reported inaccurately.

Description of development approach
use a common base class for XAML and WPF editable text.

…p voice messages (#15840)

This pull request adds mention about the fact that the whatsapp voice messages no longer freeze nvda as per #15169, and #14888.
This pull request also fixes some mistakes and typos

Description of user facing changes
Fixes for the documentation

Description of development approach
Edited the english changes.t2t

…erations library on NVDA exit. (#16222)

Fixes #16072

Summary of the issue:
As seen in a dump file provided by @irrah68 when debugging #16072 , NVDA can hang on exit while trying to destruct an instance of the CUIAutomation8 COMClass object:

Call stack
Details
In short, it looks as if the destruction of the CUIAutomation8 COMClass object held by the UIA abstraction Remote Operations library locks up as it is happening from a different thread from where it was created. It was originally created in NvDA's UIA MTA thread, but it is being automatically cleaned up by the CRT of NVDA's UIARemote.dll in NVDA's main thread. I'm not entirely sure why this is only a problem on @irrah68's machine, and why it is more likely to happen with the UIA Rate Limited event handler in #14888. Either way though, NVDA is not cleaning it up correctly.
Description of user facing changes
NVDA is less likely to hang on NvDA exit.

Description of development approach
Add a cleanup function to UIARemote.dll which calls the UIA abstraction remote operations library's cleanup function. This function frees all remote contexts, but most importantly, releases the CUIAutomation8 COMClass object which was passed in on initialization.
Add a terminate function to UIAHandler/remote.py which calls UIARemote.dll's cleanup function.
at the end of UIA's MTA thread in Python, after removing event handlers, finally call UIAHandler.remtoe.terminate, ensuring that the UIA abstraction remote ops library is correctly cleaned up in the UIA MTA thread, where it was originally initialized.

Partially reverts #14888, #15838

Summary of the issue:
In #14888, XamlEditableText was added to ensure that UIA events wouldn't be used to determine caret changes, as the hypothesis was that they were fired too early. In #15838, I expanded this workaround for WPF (Visual Studio) text controls.
It turns out @jcsteh found the actual cause of these issues and fixed them in #16711, allowing us to rely on events again.

Description of user facing changes
None, though caret movement would possibly be detected a little bit faster in XAML and WPF controls.

Description of development approach
Mostly reverts.

Fixes #6291. Partially addresses #15786, #15850, #11002, and #14189. All of these describe the same general class of "NVDA stops responding during console flood" problem but also include symptoms (UIA event flooding, NVDA crashes destroying the console window, etc.) that are out of scope for this PR and were partly addressed in #14888 and #14067 anyway. Related to #2977 and #875.

Most of these are already closed, but the underlying root cause (which is the main thread blocking during line announcement) was never actually addressed.
Summary of the issue:

When a live-text region (such as a terminal) produces a large burst of new text in a short window, NVDA's main thread blocks announcing every line sequentially, becoming unresponsive to keyboard input until the burst finishes. In some cases this lasts tens of seconds. In other (more drastic) cases, it can last so long that the user has to sign out, restart, or force-kill NVDA.
Description of user facing changes:

NVDA no longer freezes when large bursts of text are reported in a live region.
Description of developer facing changes:

LiveText._reportNewLines is no longer guaranteed to report lines synchronously. Internally, it now registers a generator with queueHandler which yields between batches of lines so the main thread can service input during long announcements.

A new class attribute LiveText.MAX_LINES caps the number of lines announced per burst. We drop everything before that on the floor.

When a new burst arrives while a previous one is still being announced, the previous generator is cancelled and the new burst supersedes it.
Description of development approach:

Live-text regions announce new text via LiveText._reportNewLines, which was invoked synchronously from the main thread's event queue. For workloads producing substantial amounts of new lines in a short window, every line traverses the full speech pipeline sequentially without yielding, which can leave the main thread unresponsive to keyboard input for tens of seconds or longer.

This PR addresses the responsiveness problem at the announcement layer rather than at the diff or event-source layer, which were previously addressed by #14888 and #14067. Specifically:

(1) Bursts larger than MAX_LINES are truncated to the most recent N lines. Skipping the oldest lines was chosen over skipping the newest because most flooding scenarios carry their actionable content at the end.

(2) Reporting now happens via a generator registered with queueHandler.registerGeneratorObject, yielding every 5 lines. This is the same primitive previously used by speech.speakSpelling and the original sayAll. Between yields, the main thread services the event queue, which keeps NVDA responsive.

(3) A handler is registered with pre_speechCanceled so that pressing control (or any other speech-cancel trigger) also cancels the in-flight generator. Perceptibly this may not cancel immediately and up to 5 lines may still be announced past the cancel, but internally the generator won't proceed past that iteration.