GNOME Bugzilla – Bug 416971
[pending] Orca does not speak or braille numbers/bullets of list items in Firefox
Last modified: 2008-07-22 19:26:57 UTC
When you navigate by line to a list item in Firefox, Orca speaks/brailles the list item text that is on the line but does not speak/braille the number or the bullet. It turns out that the characters that make up the number/bullet have extents of (0, 0, 0, 0). In getLineContentsAtOffset() we explicitly check for those extents to eliminate speaking/brailling whitespace characters that are not present in the page but happen to be present in the HTML source. Trying to distinguish between invalid versus valid characters with extents of (0, 0, 0, 0) seems a bit hacky. For instance, is the whitespace character in question merely in the HTML source, or is it the space in between the list item number and the list item text? Life would be much better if list item numbers/bullets had actual (non-zero) extents. Will, do you think the non-zero extents of the numbers/bullets is a bug in Firefox, or is intentional and thus something we have to hack around in gecko.py?
Definitely a bug in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=360003 :-(
(In reply to comment #1) > Definitely a bug in firefox: > https://bugzilla.mozilla.org/show_bug.cgi?id=360003 > > :-( But, from Aaron: "This is hard to fix so a workaround should be used for now." So...we need to put our thinking caps on.
Created attachment 85604 [details] [review] ugly hack .... but it seems to work > So...we need to put our thinking caps on. I put mine on. Then I gave up, took it off, and came up with the attached. Yes it is ugly, but it seems to work. Tested with Up/Down, I/Shift I, and L/Shift L. Thoughts? More effective caps/less ugly solutions?
Hey! You did it. I say check it in. Thanks!
Done. Thank YOU. What still remains to be done on this is getting bullets to speak. Does that mean adding them to chnames.py or something else?
Eeeks. Oh yeah. Speaking the bullets. Yech. This probably should be done via chnames as you suggest. I'm not sure on the specifics of all the Unicode symbols available, but these might be starters: Unicode - UTF-8 - string u'\u2022' - '\xe2\x80\xa2' - bullet u'\u25e6' - '\xe2\x97\xa6' - white bullet u'\u00b7' - '\xb7' - middle dot For moving forward, chnames.py probably should use unicode strings for the keys in __chnames (it's currently using UTF-8), and it would be ideal to try to find something that already provides localized names for the Unicode characters.
(In reply to comment #6) > Eeeks. Oh yeah. Speaking the bullets. Yech. This probably should be done > via chnames as you suggest. I'm not sure on the specifics of all the Unicode > symbols available, but these might be starters: > > Unicode - UTF-8 - string > u'\u2022' - '\xe2\x80\xa2' - bullet > u'\u25e6' - '\xe2\x97\xa6' - white bullet > u'\u00b7' - '\xb7' - middle dot > > For moving forward, chnames.py probably should use unicode strings for the keys > in __chnames (it's currently using UTF-8), and it would be ideal to try to find > something that already provides localized names for the Unicode characters. > I'm closing bug 418147 with the intent that the patch for this bug will include at least the ñ from niño. :-) No need to go crazy with all characters, though.
Created attachment 86846 [details] [review] add bullets and other symbols, some refactoring This patch adds bullets and a number of other symbols to chnames.py and punctuation_settings.py. This will get bullets speaking both in Firefox and elsewhere (e.g. OOo Writer documents). Note that in the former case, all bullets are exposed to us as the generic bullet character regardless of their appearance. But at least we can speak their presence now.... In addition, these two files now use unicode characters for their dictionary keys which should make it easier for users to add/edit their own dictionaries.
Created attachment 86854 [details] [review] don't echo bullets in password entries if keyecho by char is not enabled Hermann pointed out a side effect of adding bullets: We now say "black circle" in all password entries regardless of the keyecho setting. In default.py's onTextInserted() we are specifically choosing to do this. This patch takes keyecho into account before doing it. Thoughts? Also, Hermann observed that "black circle" is rather verbose. I think we want to keep descriptive bullet names because if you are formatting a document that you will be sharing with others, it's important to know what the thing looks like (e.g. that you're bullets are consistent). This, of course, does not apply to password entries. :-) Do we want special handling for password entries to just say "bullet" or "star" or something shorter??
Created attachment 86856 [details] [review] don't echo bullets in password entries if keyecho by char is not enabled AND say "star" when it is I still think that we shouldn't be echoing in this field if keyecho by char is not enabled. This version says "star" instead of "black circle" when keyecho by char IS enabled.
As per Will, I opened a new bug for this latter issue: bug #432674
Closing as FIXED.