Bug 533125 – Orca does not speak Search textbox in Firefox Download Manager if it is empty.

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 an attachment (id=111073) [edit]
proposed patch

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.