GNOME Bugzilla – Bug 533125
Orca does not speak Search textbox in Firefox Download Manager if it is empty.
Last modified: 2009-03-10 00:04:51 UTC
1. Open Firefox 3 nightly or RC1.
2. Open Tools/Downloads.
3. Press Shift+Tab to get to the Search... textbox.
Expected: Orca should speak and braille the textbox name and contents.
Actual: Orca remains silent, and the braille display shows the firefox and download manager titles.
4. Type in something.
Result: Now as something is written inside the textbox, Orca will correctly speak and braille the name and role.
In Accerciser, the textbox looks correct with name, states etc. regardless of whether there is text typed into it.
More info: Orca's "Where Am I?" command correctly identifies the name and role of the textbox, but even then does not update the braille view which still shows the window title and role only. So in principal, Orca knows where I am, but only if I ask it to tell me, not when focus moves.
I've also noticed that Orca receives several CaretMoved events when focus goes to this textbox. I've even traced it to the point in default._presentTextAtNewCaretPosition where Orca asks the text interface for the caret offsets for start and end, and in an empty textbox, it receives 0 for both, but haven't gotten to a point where I actually see it bail out of something early.
Created attachment 111073 [details] [review]
It's another case of Gecko deleting text from the entry prior to it getting focus. The default script gets the object:text-changed:delete event and decides to silently set the locusOfFocus to be that entry (because, after all, if we're deleting text in that entry, we must be in that entry, right? :-) ) Then along comes the focus event. As far as we're concerned the entry is already our locusOfFocus, so we don't want to announce anything.
We're already special-casing this scenario for the search entries in FF and Thunderbird. This patch adds a special case for Downloads.
Already pylinted, not yet regression tested, seems to work. Please test.
> It's another case of Gecko deleting text from the entry prior to it getting
> focus. The default script gets the object:text-changed:delete event and
> decides to silently set the locusOfFocus to be that entry (because, after all,
> if we're deleting text in that entry, we must be in that entry, right? :-) )
> Then along comes the focus event. As far as we're concerned the entry is
> already our locusOfFocus, so we don't want to announce anything.
Oh yes right, these are all instances where the "label" of the entry is actually a default text that goes away once focus gets there. I had forgotten about that detail.
I tested the patch, and it works in both Downloads and Add-Ons Managers.
The only point I have is this: While speech now properly speaks the prompt and text (if any), braille only shows the frame title, and if the entry contains text froma previous search or I just typed something, it'll show that as well, but in both cases, it omits the label for the entry. On the "Search using Google" entry, the label is shown properly.
The "Search using Google" entry is a child of an autocomplete. The decision was made at some point (before my time) to treat autocompletes differently in braille and use the name of the autocomplete as the braille label. The entry in question is just an entry. Therefore, it gets handed off to the default generators. In the case of braille, we look for the displayed label. There is no label present, displayed or otherwise. It would be nice if there were a label there for us to display. <smile>
So the question is: Do we want to special case this particular entry as well (i.e. just in Gecko)? I assume that we don't normally (i.e. across the board in all of Orca) want to be displaying entry names in the braille context, but then again....
Will, Mike: Please advise.
Lets file an enhancement request and get this fixed at the application level.
Enhancement request here: https://bugzilla.mozilla.org/show_bug.cgi?id=434249
This passes the regression tests. Will, okay to check this in to handle the speech side of things?
I chatted with Will about this via IM. I have committed the patch to trunk based on Marco's report that it solves the problem on the speech end, that it pylints, and that it passes the regression tests.
I am retitling this bug to reflect just the speech portion of the problem as that has been addressed. I have opened bug #533660 for the braille issue and am blocking it for now against the enhancement request I filed.
Moving this one to pending.
Patch also committed to the gnome-2-22 branch.