GNOME Bugzilla – Bug 412100
Text selection is not announced in Firefox
Last modified: 2016-06-04 16:42:31 UTC
When Orca is controlling the caret, pressing Shift plus the arrow keys does not cause text to be selected. The current work-around seems to be to allow Gecko to control the caret by pressing Orca Modifier + F12, select the text, and return control to Orca when finished. Note that when using this work-around, Orca doesn't speak selected text as it does in other environments. However, it does correctly announce the new location of the caret.
This is definitely a problem, and is more encouragement for users to try to persuade the Firefox team into providing reliable caret navigation. There are a couple bugs in Firefox for this: Caret navigation metabug: https://bugzilla.mozilla.org/show_bug.cgi?id=241023 Structural navigation bug: https://bugzilla.mozilla.org/show_bug.cgi?id=321632
> This is definitely a problem, and is more encouragement for users to try to > persuade the Firefox team into providing reliable caret navigation. Agreed!! Is this something we can try to handle on our end or is this really something that is blocked until the Firefox team improves things on their end?
Selection from our end via the AT-SPI is going to be somewhat of a hairball since it easily crosses over object boundaries and becomes more complex to express, let alone make happen.
Sorry to quote myself, but w.r.t. this: > Note that when using this work-around, Orca doesn't speak selected text as it > does in other environments. However, it does correctly announce the new > location of the caret. I was thinking that we could at least make the user experience better by announcing what text was selected/unselected *if Gecko were controlling the caret*. Unfortunately, we can't even do that because getNSelections() always returns 0. See https://bugzilla.mozilla.org/show_bug.cgi?id=369389.
https://bugzilla.mozilla.org/show_bug.cgi?id=369389 has been closed as FIXED and we are now getting valid values from getNSelections(). Now it's just a matter of handling selection depending on who is controlling the caret. :-)
> When Orca is controlling the caret, pressing Shift plus the arrow keys does not > cause text to be selected. The current work-around seems to be to allow Gecko > to control the caret by pressing Orca Modifier + F12, select the text, and > return control to Orca when finished. If Orca were to provide this functionality, I'm curious if FF supports the selection of text via the AT-SPI (i.e., can Orca programmatically cause text to be selected in Firefox?).
I started looking at this. We're not always getting valid starting offsets from getSelection(). See: https://bugzilla.mozilla.org/show_bug.cgi?id=387273 I can hack around it, but if they fix it on the Firefox side of things there shouldn't be a need to make a Gecko.py-specific isTextSelected() or speakTextSelectionState()
> I'm curious if FF supports the selection of text via the AT-SPI > (i.e., can Orca programmatically cause text to be selected > in Firefox?). Seems that we can: text.setSelection() works.
I'm changing the summary to reflect that we are blocked. Life will be much better when we're not getting bogus starting offsets....
Officially we are unblocked on this one. After I get more of the regression testing done I'll work on it. :-)
Trying to balance optimism with realism, I'm nudging the target back slightly. I still would like to get this in the 2.22 release, but we have to get the line nav stuff worked out.
These simptoms can also be seen in thunderbird 3. The same applies to the message window while reading messages as well as to the composition window.
First coarse pass at GNOME 2.24 planning.
*** Bug 547499 has been marked as a duplicate of this bug. ***
Working this function your openion with 2.26 release with Orca? I seeing the svn trunk release with following simptoms in FF3 and Thunderbird: The selection is happened, but the selected text is not spokened. I looking this with GNOME 2.22 and Orca svn trunk version. I looking this with GNOME 2.24 in monday. Attila
I'm afraid it's looking like we might not get to this in time for the release. :-( Hopefully the one after that.
In terms of the 2.26 release, we won't have perfect selection support, but I might be able to get some rudimentary support implemented to make selecting from with large blocks of text work. It's at least a start. Retargeting and planning to do the best I can in the days that follow. :-)
We are late in the 2.28 release cycle and I want to focus on "high impact"/"low risk" items that also fall within the release team's restrictions in place. Regretfully, this bug doesn't fit well within those constraints and we'll review it for the 2.29 release cycle.
This really needs doing. It's also really likely to be a pain in the arse to put it bluntly given Geckoisms, Gecko's broken caret navigation, etc. Volunteers welcome.
Point of clarification: with Firefox 4.0 Beta, I just tried the suggested strategy of switching to Gecko navigation while selecting text. All I could get was the word "selected" spoken with eath press of the shifted or ctrl-shifted arrow keys. Pressing the WhereAmI key just yields silence. It wouldn't be so bad if at least that key could speak what text is currently selected.
I see that this bug has been around for some time and is of high importance; I'm in full agreement with that. I also want to be able to hear selected text from gecko. I'm willing to take a stab at it. I'm giessing the bulk of the activity may be hounding the Mozilla devs to get their buts moving on this. Also, I would need to work the text selection along with Accerciser to see if/what events are exposing when selecting text. I see it as a learning experience as well as an exercise in patitioning other developers to improve application compatibility. I will probably need some help on this based on what I've read so far.
*** Bug 721149 has been marked as a duplicate of this bug. ***