GNOME Bugzilla – Bug 588910
Orca should support the spellcheck as you go in mozilla applications
Last modified: 2009-11-09 21:35:15 UTC
Firefox and thunderbird can show miss spelled words. It would be really useful if orca could let the user know this information. What I'd like is the following: If the cursor lands on a word orca should first say miss spelled before saying what it normally would. A couple examples are as follows: If control+right arrow were used to move to a miss spelled word we would hear "miss spelled" followed by the word. If simply right arrow were pressed we would hear "miss spelled followed by the first leter of the word.
What if the user has just finished typing a word and the red squiggly line appears? This might be handy for users who review their text by line. Also, if the user moves to a word as you describe and then presses Right Arrow again to arrow to the second character in that word, do we speak the error again?
Created attachment 138650 [details] [review] take 1 This is the simplest implementation, namely if we are presenting a character or word and the word is misspelled, we speak "misspelled" as Mike described. Mike, I need your recommendations for the questions I raised in my previous comment. Based on what you suggest, I'll come up with a new patch as needed. Thanks.
Is there something we can do for braille as well?
(In reply to comment #1) > What if the user has just finished typing a word and the red squiggly line > appears? This might be handy for users who review their text by line. If you mean should we say miss spelled after the user presses space I think this is a good idea. > > Also, if the user moves to a word as you describe and then presses Right Arrow > again to arrow to the second character in that word, do we speak the error > again? no >
(In reply to comment #3) > Is there something we can do for braille as well? > We already are. By default, invalid is amongst the formatting attributes which we "underline" in braille. If you have braille "underlining" enabled for text attributes (we default to None), the squiggly lines should show up in the braille. At least they do for me. Or did you have something else in mind?
One other small thing: I think we should only speak this information in verbose verbosity. I have not yet thought of anything creative to do for the braille user for this feature.
(In reply to comment #5) > We already are. By default, invalid is amongst the formatting attributes which > we "underline" in braille. D'Oh. Right. There it is -- "invalid". Ugh. I was looking for something related to the work "spelling". According to https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs, it looks like the attribute is 'invalid' and the value is 'spelling'. If 'spelling' is going to be the only possible value, I wonder if we should expose 'invalid' as 'spelling' in text_attribute_names.py?
(In reply to comment #7) > (In reply to comment #5) > > We already are. By default, invalid is amongst the formatting attributes which > > we "underline" in braille. > > D'Oh. Right. There it is -- "invalid". Ugh. I was looking for something > related to the work "spelling". According to > https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs, it > looks like the attribute is 'invalid' and the value is 'spelling'. If > 'spelling' is going to be the only possible value, I wonder if we should expose > 'invalid' as 'spelling' in text_attribute_names.py? > What if someone implements 'grammar'?
Created attachment 138703 [details] [review] take 2 This makes the changes Mike indicated, namely: 1. Only do this for the verbose level of speech 2. Only present the error when the user first crosses into the misspelled word As for announcing the sudden appearance of the red squiggly line when the user presses space, that is looking like it might prove harder than I first believed. :-( When the red squiggly line suddenly appears, Gecko does emit an object:text-attributes-changed event. Currently we don't listen for those, but we can. Unfortunately, it seems that all this event tells is "something changed somewhere" w.r.t. the text attributes of the event.source: event.detail1 and event.detail2 are both 0, and event.any_data is None. Therefore, I believe implementing this part of the RFE would require our always keeping track of text attributes for the locusOfFocus and doing a comparison. I haven't given up on this yet, but I need to walk away from it for a bit and mull it over. Therefore I'm attaching what I have for consideration and review. Thanks!
Created attachment 138711 [details] [review] take 3: how many hacks can dance on the head of a pin? :-) Okay, I figured out a way to present the sudden appearance of the red squiggly line. It's a hack, but it's a hack limited to the Gecko script and which seems to work. Mike please test. Will please review. If it's deemed worthy, I'll then run the full suite of regression tests. Thanks!
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > > We already are. By default, invalid is amongst the formatting attributes which > > > we "underline" in braille. > > > > D'Oh. Right. There it is -- "invalid". Ugh. I was looking for something > > related to the work "spelling". According to > > https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs, it > > looks like the attribute is 'invalid' and the value is 'spelling'. If > > 'spelling' is going to be the only possible value, I wonder if we should expose > > 'invalid' as 'spelling' in text_attribute_names.py? > > > What if someone implements 'grammar'? I think 'invalid' is a rather obtuse word that doesn't describe the intended text attribute very well. Maybe 'mistake' might be a more descriptive word choice?
(In reply to comment #10) > Created an attachment (id=138711) [edit] > take 3: how many hacks can dance on the head of a pin? :-) > > Okay, I figured out a way to present the sudden appearance of the red squiggly > line. It's a hack, but it's a hack limited to the Gecko script and which seems > to work. > > Mike please test. Will please review. If it's deemed worthy, I'll then run the > full suite of regression tests. Thanks! I think this looks OK and I think it may be fine to put the entire implementation in the default script rather than just Gecko.
(In reply to comment #11) > I think 'invalid' is a rather obtuse word that doesn't describe the intended > text attribute very well. Understood. > Maybe 'mistake' might be a more descriptive word choice? Or 'error'? While changing 'invalid' to something else is a separate bug, I'll add it to the next version of the patch for this bug. Do you prefer 'mistake' over 'error'?
(In reply to comment #13) > > Maybe 'mistake' might be a more descriptive word choice? > > Or 'error'? > > While changing 'invalid' to something else is a separate bug, I'll add it to > the next version of the patch for this bug. Do you prefer 'mistake' over > 'error'? Agreed it is a separate issue that came out of me not realizing 'invalid' was the thing to check for spelling mistakes. Including the change as part of this bug is OK, but if you want a separate bug, I'll be happy to open one since I'm the stickler for one bug per problem report. I prefer 'mistake' over 'error' because even 'error' can be more ambiguous (e.g., was there a system error rendering the text?).
(In reply to comment #14) > Agreed it is a separate issue that came out of me not realizing 'invalid' was > the thing to check for spelling mistakes. Including the change as part of this > bug is OK, but if you want a separate bug, I'll be happy to open one since I'm > the stickler for one bug per problem report. It's an easy change. In fact, I just made it. :-) So no need for a new bug. I'm going to write up a Gecko regression test for this new feature and then attach a new patch with it, the language change, and the move-things-to-default.py change. > I prefer 'mistake' over 'error' because even 'error' can be more ambiguous > (e.g., was there a system error rendering the text?). Okie dokie. Done.
Created attachment 138760 [details] [review] take 4: Make the changes Will suggested; add a regression test This version: * Moves the functionality from onTextAttributesChanged & speakMisspelledIndicator out of the Gecko script and into the default script. (I left the functional isWordMisspelled in the Gecko script because one day the Gtk+ text widget might start exposing the necessary information -- and do so differently than Gecko does it.) * Causes the attribute name 'invalid' to be presented to the user as 'mistake'. * Adds a new Firefox regression test into the mix. Something odd is happening with the cursor position in braille, but it's happening without this patch as well, so I just flagged it as a "BUG?" for now in the test. Speaking of tests, looks like we need to update the gtk-demo tests and the OOo Writer tests to be compatible with OpenSolaris dev. That said, I ran those tests with this patch and this patch does not seem to be introducing any regressions/changes. I'll run the Firefox tests now.
Created attachment 138775 [details] [review] take 5: Final version (I hope) - wrap queryText in try/except Nothing catches bad assumptions like three full hours of Firefox regression tests. :-) I was assuming that we would not find ourselves in speakMisspelledIndicator unless we were looking at something which implemented the accessible text interface. D'oh! I know better than that with Firefox. Anyhoo... The only difference between this version of the patch and the previous one is that it wraps a call to queryText in a try/except. This solves the regressions. I believe I am finally done with this enhancement request.
Thanks a lot for doing this one. I think users will really find it useful.
Thanks Mike. Will, final review before commit please. Thanks!
Looks awesome. Many thanks!
Thanks guys! Patch committed to master. Closing as FIXED. Wiping brow. :-)
Great job!!! thanks. Would be possible speak Misspelled Indicator using a different voice? Thanks again.
(In reply to comment #22) > Great job!!! thanks. > Would be possible speak Misspelled Indicator using a different voice? > Thanks again. > That's definitely an interesting idea. We have (at least) two bugs opened related to implementing support for additional voices: bug 543157 and bug 412656. Because I don't want your idea to get forgotten about, I've added your comment to both of those bugs so that it remains on our radar. Thanks!
Joanmarie, the following string always untranslated spokening, but this string is presented my hungarian translation file and I translated correct: #. Translators: this attribute specifies there is something "wrong" with #. the text, such as it being a misspelled word. See: #. https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs #. #: ../src/orca/text_attribute_names.py:133 msgctxt "textattr" msgid "mistake" msgstr "Hiba:" If I use for example with Thunderbird application and write "Netbook Remix" words with mistakes (netbook remix the correct words), when I navigating this words, Orca correct says the mistake hint ("hibásan írt szó" in hungarian translation). When I press one right arrow and press Orca+f key combination, orca says following text attribute: "mistake betűtévesztés." The "betűtévesztés" is the hungarian translation (this is correct), the mistake is the untranslated string part. If the translation of this string work right (now not work), Orca wish says: "hiba: betűtévesztés."
Thanks Attila! I'll take a look. Reopening.
Issue confirmed. Turned out I included invalid/mistake in a dictionary used for conversion and I shouldn't have. Removing it has no impact on what is displayed and spoken for English and passes the regression test we have for this feature. Fix committed to master: http://git.gnome.org/cgit/orca/commit/?id=3ba03f5221e4444e6327e043d30a5c1ac05a663a In addition, in my local install, I updated my hu.po file as Attila described in commment #25 to confirm that my fix works. Now when I press Orca+f, I get the following speech output: 'méret 9pt' 'betűkészlet monospace' 'Hiba: betűtévesztés' I also see 'Hiba:' in the list of attributes in the Orca Preferences dialog; before my fix I saw 'mistake' here as well. Re-closing as FIXED.
(In reply to comment #9) > This makes the changes Mike indicated, namely: > > 1. Only do this for the verbose level of speech Perhaps so late, but instead of do this for the verbose level, I'd prefer an option to toggle.