GNOME Bugzilla – Bug 658134
Lines with unexpected characters are not always displayed in braille by Orca
Last modified: 2012-08-14 20:36:58 UTC
+++ This bug was initially created as a clone of Bug #658133 +++ Step to reproduce: 1. Try to read this content with Orca using Firefox 6: http://lists.fedoraproject.org/pipermail/announce/2011-August/002992.html Expected result: It would work. Actual result: It fails due to UnicodeEncodeError exceptions. Note: I was able to stop Orca from spitting up and present the lines in question in speech quite easily. Something else seems to be going on in braille necessitating further investigation.
Created attachment 195725 [details] [review] Fixes some more Unicode exceptions. This fixes a Braille-related exception that I was getting as well as a few exceptions generating speech from Firefox. I'm not at all sure that this fixes all of the exceptions and don't really like the loose function that I added. I think it would be good for Orca to only use one encoding for strings internally, encoding and decoding as needed when communicating with other modules (perhaps decoding all strings to Unicode as they come from pyatspi, for instance), but that would take more time than we have right now. Also, adjustForDigits was encoding its return value to UTF-8, and speechdispatcherfactory.py was calling it and trying to encode the string to UTF-8 again, causing an exception if there were non-ASCII characters. adjustForDigits is only called by speechdispatcherfactory.py, so it is safe to change it. It looks like string operations that involve any Unicode string cause the returned result to be promoted to Unicode. This all makes me wonder if Python 3 does anything different in regard to Unicode.
Review of attachment 195725 [details] [review]: Well, at least another sanity check might be in order as I am now seeing a different issue: Traceback (most recent call last):
+ Trace 228340
eval(evalString, globalsDict)
Region.__init__(self, string, cursorOffset, expandOnCursor)
string = orca_state.activeScript.utilities.decodeUTF8(string)
Furthermore, I agree with you about needing to deal with encoding in just one place ideally. So.... Maybe the thing to do is get 3.2 out the door and then add this to our (admittedly growing) refactor list.
Created attachment 195734 [details] [review] Updated patch. Updated not to use the script.utilities function in braille.py
So it turns out the problem is bigger than just Firefox. As discovered while fixing bug 658781, this line is not being displayed in braille for Gedit: Author: Мирослав Николић <miroslavnikolic@rocketmail.com> in addition to not being displayed for Firefox. Related aside: Because I hadn't looked at your patch yet, I didn't realize that it included some additional changes beyond what you did in braille.py. Therefore while fixing 658781, I wound up catching the things I'd missed before, which you addressed in your patch. Sorry about that! Anyhoo.... Focusing on the braille.py change and this new test case: If I make the change you propose, namely: - try: + if not isinstance(string, unicode): string = string.decode("UTF-8") - except UnicodeEncodeError: - debug.printException(debug.LEVEL_SEVERE) The following occurs in Gedit: We see that string is unicode, therefore we do not try to decode it, and we do not print the exception. The other thing we do not do is display the line in braille (i.e. at least for me, your check fails to fix the bug). I'm going to look into this some more because now this ascii codec spit ups are personal. <grins>
Heh. Some of the issue seemed to be specific to my debugging level. Another issue is that when I reinstalled rawhide I couldn't get my hardware braille display working so I have been using the braille monitor for the past couple of weeks. And the braille monitor code was silently swallowing the exception and changing the text to show to an empty string. Some days I'm an idiot. Anyhoo, with the following commit, the new test case is being displayed in braille on the braille monitor, both for gedit and for firefox. http://git.gnome.org/browse/orca/commit/?id=2aa1c65ce6a9b9d1b57815a4dd3cdf42db3697ab I'll see if I can get my hardware display working in rawhide, but if anyone wants to verify this bug is fixed in the meantime, please let me know.