GNOME Bugzilla – Bug 495303
Character flat review not working correctly with generated texts in XUL
Last modified: 2008-11-26 14:45:20 UTC
Please describe the problem: Orca flat review doesn't work correctly on dynamically added texts in XUL applications. Instead of reviewing single characters it reviews whole pieces of texts from the current character to the end of the given text. Steps to reproduce: 1. Fetch the file http://www.freebsoft.org/~pdm/test8a.xul 2. Display it in the chrome mode in Firefox 3, by using the command line option `-chrome test8a.xul'. 3. Press the "Add text" button. 4. Use Orca flat review to review characters in various pieces of the text (e.g. by using the KP-1/2/3 keys), especially in "some text" and in "generated text". Actual results: Flat review works as expected in "some text". But in "generated text" rest of the text from the current character position is reviewed instead of just a single character. Expected results: Character flat review should work the same way in both "some text" and "generated text", i.e. reviewing just single characters. Does this happen every time? Yes. Other information:
I just looked at this via accerciser, and it appears as though there's a bug somewhere: the objectionable text areas seem to give us empty accessible text. As such, flat review just ends up making guesses. I'm not sure if the bug is in the XUL source code example: <description style="-moz-user-focus: normal">some text</description> <description style="-moz-user-focus: normal" value="label text"/> <box id="mybox"/> <description style="-moz-user-focus: normal">other text</description> <button label="Add text" oncommand="mycallback()"/> Or, there may be something wrong with how Gecko is giving text to us. I'm adding Aaron Leventhal to the CC list of this bug to see if he can provide some insight.
Using Accerciser's iPython Console, I tried to get just the 4th character of 'generated text': In [1]: text = acc.queryText() In [2]: text.getTextAtOffset(3, TEXT_BOUNDARY_CHAR) Out[2]: ('erated text', 3, 14) Doing the same thing for 'some text' works as expected: In [3]: text = acc.queryText() In [4]: text.getTextAtOffset(3, TEXT_BOUNDARY_CHAR) Out[4]: ('e', 3, 4) I filed a Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=464559 Marking as blocked but I think I can hack around this safely.
Created attachment 122527 [details] [review] be sure we just have one character's worth Will, are there other times where getTextAtOffset might return more than one character's worth for TEXT_BOUNDARY_CHAR but we *wouldn't* want to do this?
(In reply to comment #3) > Created an attachment (id=122527) [edit] > be sure we just have one character's worth > > Will, are there other times where getTextAtOffset might return more than one > character's worth for TEXT_BOUNDARY_CHAR but we *wouldn't* want to do this? I believe getTextAtOffset returns UTF-8, so a single multibyte character would end up causing bytes to be lost in your current check. So, I think you might need to make sure your length check is done on a unicode string.
Created attachment 122531 [details] [review] take 2 (pun intended) Sorry Will. I know it does.... Just wasn't thinking.... That's what I get for trying to knock a few bugs out too quickly. This version still seems to solve the problem while not blowing up on web pages with accented characters. ;-) Unless I'm still being an airhead, do you think this is worth doing?
(In reply to comment #5) > This version still seems to solve the problem while not blowing up on web pages > with accented characters. ;-) Unless I'm still being an airhead, do you think > this is worth doing? It seems worthwhile and looks like it should work well. Thanks! If it pylints and regression tests, please commit. :-)
Patch committed to trunk. After it's been tested a bit more I'll commit it to the gnome-2-24 branch as well.
Patch committed to the gnome-2-24 branch for inclusion in the 2.24.2 release.