After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 533125 - Orca does not speak Search textbox in Firefox Download Manager if it is empty.
Orca does not speak Search textbox in Firefox Download Manager if it is empty.
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
unspecified
Other All
: Normal normal
: 2.24.0
Assigned To: Joanmarie Diggs (IRC: joanie)
Orca Maintainers
Depends on:
Blocks: 404403
 
 
Reported: 2008-05-14 15:17 UTC by Marco Zehe
Modified: 2009-03-10 00:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (1.28 KB, patch)
2008-05-17 20:04 UTC, Joanmarie Diggs (IRC: joanie)
committed Details | Review

Description Marco Zehe 2008-05-14 15:17:24 UTC
Steps:
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.
5. Tab.
6. Shift+Tab.

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.
Comment 1 Marco Zehe 2008-05-17 10:51:39 UTC
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.
Comment 2 Joanmarie Diggs (IRC: joanie) 2008-05-17 20:04:33 UTC
Created attachment 111073 [details] [review]
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.
Comment 3 Marco Zehe 2008-05-17 20:29:40 UTC
> 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.
Comment 4 Joanmarie Diggs (IRC: joanie) 2008-05-17 21:22:32 UTC
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.
Comment 5 Mike Pedersen 2008-05-17 22:16:00 UTC
Lets file an enhancement request and get this fixed at the application level.  
Comment 6 Joanmarie Diggs (IRC: joanie) 2008-05-17 23:48:23 UTC
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?
Comment 7 Joanmarie Diggs (IRC: joanie) 2008-05-18 03:22:55 UTC
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.
Comment 8 Joanmarie Diggs (IRC: joanie) 2008-05-18 03:31:42 UTC
Patch also committed to the gnome-2-22 branch.