GNOME Bugzilla – Bug 408670
Braille and speech don't track well in text entry areas in Firefox and Thunderbird
Last modified: 2007-04-03 16:53:10 UTC
When editing text in autocompletes, single line text areas, and multiline text areas, braille and speech don't always seem to track well. We'll sometimes here "newline" over and over, and we'll also see nothing but blank cells on the braille display. This occurs when composing messages in Thunderbird, when entering bug reports in http://bugzilla.gnome.org.
Created attachment 82694 [details] [review] Rejected patch that solved the problem, but hurt viewing of HTML messages in Thunderbird Here's an attempt at patching this for Thunderbird. It had a bad side effect of preventing the viewing of HTML messages, so it's been backed out. But...I want to put it here for future reference.
Created attachment 83675 [details] [review] Patch to clear unicode cache on text inserted and deleted events Phew - this one was tough to track down. It turns out that the caching of unicode text values got in the way here. The ultimate solution was to delete the unicode cache when we detected text insertions and deletions. It also needed a little work to handle a case where the caret was at the very end of a text object (as is often the case when we're composing a document).
Created attachment 83692 [details] [review] Improved patch to treat an editable document frame like a text area This new and improved patch builds on the previous patch. focuses on the composition area of Thunderbird, and treats an editable document frame as a text area. This gets us the " $l" handling at the end of the line and also seems to work better with the "old" Thunderbird from a few weeks ago and the new Thunderbird built from Mozilla CVS this morning.
Will, this seems to work nicely in Firefox. Is there anything else that needs to be done on it?
Thanks for the check. Closing as FIXED. We can open another bug if something else crops up.