After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 551077 - Traceback and loss of speech in OOo Writer docs with both links and multbyte characters on the same line
Traceback and loss of speech in OOo Writer docs with both links and multbyte ...
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.23.x
Other All
: Normal normal
: 2.24.0
Assigned To: Orca Maintainers
Orca Maintainers
: 541762 (view as bug list)
Depends on:
Blocks: 404411
 
 
Reported: 2008-09-06 06:04 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2009-03-10 00:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
aforementioned test case (8.12 KB, application/vnd.oasis.opendocument.text)
2008-09-06 06:05 UTC, Joanmarie Diggs (IRC: joanie)
  Details
proof-of-concept hack for a brlmon.py issue/traceback (580 bytes, patch)
2008-09-07 04:19 UTC, Joanmarie Diggs (IRC: joanie)
committed Details | Review

Description Joanmarie Diggs (IRC: joanie) 2008-09-06 06:04:43 UTC
Steps to reproduce:

1. Open the (to be) attached test case

2. Arrow to Up/Down to the first line of links

Expected results: The links on that line would be "underlined" in braille and the full line would be spoken.

Actual results: The links are correctly "underlined" in braille, but nothing is spoken due to the following traceback:
------------------------------
Traceback (most recent call last):
  • File "/usr/lib/python2.5/site-packages/orca/focus_tracking_presenter.py", line 625 in _processObjectEvent
    s.processObjectEvent(event)
  • File "/usr/lib/python2.5/site-packages/orca/script.py", line 319 in processObjectEvent
    self.listeners[key](event)
  • File "/usr/lib/python2.5/site-packages/orca/scripts/StarOffice.py", line 2677 in onCaretMoved
    default.Script.onCaretMoved(self, event)
  • File "/usr/lib/python2.5/site-packages/orca/default.py", line 3274 in onCaretMoved
    self._presentTextAtNewCaretPosition(event)
  • File "/usr/lib/python2.5/site-packages/orca/default.py", line 3167 in _presentTextAtNewCaretPosition
    self.sayLine(event.source)
  • File "/usr/lib/python2.5/site-packages/orca/default.py", line 2113 in sayLine
    line = self.adjustForLinks(obj, line)
  • File "/usr/lib/python2.5/site-packages/orca/default.py", line 5767 in adjustForLinks
    punctuation_settings.getPunctuationInfo(line[link.endIndex])):
  • File "/usr/lib/python2.5/site-packages/orca/punctuation_settings.py", line 232 in getPunctuationInfo
    character = character.decode("UTF-8")
  • File "/usr/lib/python2.5/encodings/utf_8.py", line 16 in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb7 in position 0: unexpected code byte
------------------------------

This problem does not occur for the second line of links (i.e. we speak and braille that correctly).

This bug has been present since the implementation of "verbalized links" (Orca revision 3864).
Comment 1 Joanmarie Diggs (IRC: joanie) 2008-09-06 06:05:45 UTC
Created attachment 118146 [details]
aforementioned test case
Comment 2 Willie Walker 2008-09-06 10:13:58 UTC
In looking at the code, I think there's an assumption we're working with strings where each element is a character.  If we make adjustForLinks follow the same pattern as adjustForRepeats, it might fix this problem.

The pattern is:

line = line.decode("UTF-8")
....do some work and change line...
return line.encode("UTF-8")
Comment 3 Willie Walker 2008-09-06 14:31:21 UTC
(In reply to comment #2)
> In looking at the code, I think there's an assumption we're working with
> strings where each element is a character.  If we make adjustForLinks follow
> the same pattern as adjustForRepeats, it might fix this problem.
> 
> The pattern is:
> 
> line = line.decode("UTF-8")
> ....do some work and change line...
> return line.encode("UTF-8")
> 

See also the patch attached to http://bugzilla.gnome.org/show_bug.cgi?id=527022#c26. It seems to fix this problem.  We can split the patch apart to fix just this bug if the rest of the patch is no good.
Comment 4 Joanmarie Diggs (IRC: joanie) 2008-09-06 15:18:56 UTC
Did some manual testing. It seems to be working to solve both issues. Running the regression tests now.  Thanks!!!
Comment 5 Joanmarie Diggs (IRC: joanie) 2008-09-06 17:14:39 UTC
*** Bug 541762 has been marked as a duplicate of this bug. ***
Comment 6 Willie Walker 2008-09-06 18:17:57 UTC
The patch attached to
http://bugzilla.gnome.org/show_bug.cgi?id=527022#c26 has been committed. Closing this as FIXED.  Thanks for testing Joanie!
Comment 7 Joanmarie Diggs (IRC: joanie) 2008-09-07 04:19:26 UTC
Created attachment 118197 [details] [review]
proof-of-concept hack for a brlmon.py issue/traceback

Will, while looking at another bug I discovered that this change can cause a traceback in brlmon.py. Try tabbing to the 'Browse...' button when creating a new attachment in GNOME's Bugzilla. If the braille monitor is enabled, we won't speak the button. Probably impacts around two Orca users, but as one of those two.... ;-)

I debugged it briefly. The mask is shorter than the string because braille.getLineInfo() seems to be in charge of ellipses replacement, but the Region class is basing the mask length on the original string. The attached is just a proof-of-concept/hack which fixes the problem as I wasn't sure what the BestWay(tm) might be. I've also not tested it beyond the test case in question.

I'm making good progress on the post-link-whitespace issue. Depending on how that progresses, I'll revisit the issue here. If you beat me to it, I promise not to complain though. ;-)

Thanks!!
Comment 8 Willie Walker 2008-09-07 11:27:36 UTC
Looks good.  Please commit.  Thanks!
Comment 9 Joanmarie Diggs (IRC: joanie) 2008-09-07 21:22:32 UTC
Clearly my understanding of the braille code leaves something to be desired. The patch certainly looks and seems harmless and like the right thing to do, but the regression tests spit up mightily on it.  Some need updating because of Will's patch for this bug, so I'm going to start fresh and clean, update the tests, and go from there.
Comment 10 Joanmarie Diggs (IRC: joanie) 2008-09-07 22:50:46 UTC
Update. The tests are hosed without the patch. Then I remembered a change Will suggested be made to dbusserver.py With that change the hosed tests are no longer hosed (sans patch). After I finish updating tests, I will revisit this patch again.
Comment 11 Joanmarie Diggs (IRC: joanie) 2008-09-08 06:26:55 UTC
Issues resolved. Patch committed to trunk as-is. Re-closing.