Is this an orca or Firefox problem?  This one is pretty serious as it makes filing bugs a real problem.  

> Is this an orca or Firefox problem?  This one is pretty serious as it makes
> filing bugs a real problem.  

Just looked at this.  It turns out that it's neither.  Instead it's a page coding problem.  Check this out:

<label for="op_sys" accesskey="o">
<select name="op_sys" id="op_sys">
<option value="All" selected>All</option>
<option value="AIX">AIX</option>
<option value="BSDI">BSDI</option>
<option value="Cygwin">Cygwin</option>
<option value="GNU Hurd">GNU Hurd</option>
<option value="HP-UX">HP-UX</option>
<option value="IRIX">IRIX</option>
<option value="Linux">Linux</option>
<option value="FreeBSD">FreeBSD</option>
<option value="NetBSD">NetBSD</option>
<option value="OpenBSD">OpenBSD</option>
<option value="opensolaris">opensolaris</option>
<option value="OSF/1">OSF/1</option>
<option value="Solaris">Solaris</option>
<option value="BeOS">BeOS</option>
<option value="Macintosh">Macintosh</option>
<option value="Neutrino">Neutrino</option>
<option value="OS/2">OS/2</option>
<option value="Windows">Windows</option>
<option value="OpenVMS">OpenVMS</option>
<option value="other">other</option>
</select>
</label>

In other words, the designers of this page, in their infinite wisdom, have declared that the label for the combo box consists of the entire contents of the combo box.  Firefox is just reporting the official label to us and we're happily speaking it. <sigh>

I will look into detection/avoidance techniques.  I'm also adjusting the summary to reflect the true problem.

In the above case, the label does not have a state of visible.  Valid labels do.  By valid I mean the expected structure of:

<label for="blah">My Nifty Combobox</label>
<select name="blah">
...
</select>

So.... We could check in default.py's getDisplayedLabel() to see if the label is visible....  But given that:

1. It's a hack that shouldn't be all that frequently encountered
2. It's a problem unique to Firefox/Gecko.py
3. It seems like we're going to have to do our own label-guesswork anyway because that does not appear to be a top priority for the Firefox folks

perhaps what makes the most sense is to make a Gecko.py-specific getDisplayedLabel() that starts with the functionality of default.py's getDisplayedLabel(), checks for bogusity like the instance Mike pointed out, and then starts doing the guesswork we're going to implement.  Will what do you think?

> So.... We could check in default.py's getDisplayedLabel() to see if the label
> is visible....  But given that:
> 
> 1. It's a hack that shouldn't be all that frequently encountered
> 2. It's a problem unique to Firefox/Gecko.py
> 3. It seems like we're going to have to do our own label-guesswork anyway
> because that does not appear to be a top priority for the Firefox folks
> 
> perhaps what makes the most sense is to make a Gecko.py-specific
> getDisplayedLabel() that starts with the functionality of default.py's
> getDisplayedLabel(), checks for bogusity like the instance Mike pointed out,
> and then starts doing the guesswork we're going to implement.  Will what do you
> think?

Sounds like a good approach to take.  I wish we didn't have to copy code, though.  I wonder if there's a better way to do this (e.g., is there a refactoring opportunity for getDisplayedLabel?  Should it return an object and not a string?).

> Sounds like a good approach to take.  I wish we didn't have to copy code,
> though.  I wonder if there's a better way to do this (e.g., is there a
> refactoring opportunity for getDisplayedLabel?  Should it return an object and
> not a string?).

Well, I don't *think* there's that much code to copy really.  If we're in a document frame, we want to check for RELATION_LABELLED_BY  (i.e. the very top bit of getDisplayedLabel()).  However, the bulk of getDisplayedLabel() is looking for objects which have a panel or filler as parent -- something I didn't think applied in the context of a document frame.  

In the wouldn't-ya-know-it department, we cannot count on the bogus label not having a state of visible.  Time to find a different hack.... :-(

Because this is a unique page coding problem (how many combo boxes in the world at large have been labelled in this fashion?) in our very own bugzilla, rather than add a hack to examine each combo box to see if its label just so happens to consist of its contents, I filed a bug against bugzilla's layout component explaining the problem and proposing a solution.  Hopefully they'll be able to solve this one for us!  See bug #433527.

In the good-news/bad-news department:  This is doesn't look like it's going to be that bad to hack around after all.  In this specific case, the child of the label is the combo box.  After experimenting with various and sundry proper and improper uses of <label></label> I've come to the conclusion that there is one-to-one correspondence between the label consisting of the entire contents of the combo box and the label having a single child that is said combo box.  That's the good news.  

The bad news is that HTML combo boxes up and changed on us effective the 4/26 build of Firefox.  Now the selectable are list items rather than menu items which, as Will might say, "blows chunks" on several fronts.  I am hoping that this change was not intentional and have emailed Aaron privately to ask him about it.  As soon as I hear back, I'll either file a bug against Firefox, adjust Gecko.py, or both.  Then I'll post a patch that handles this bug.

And, yeah, Will you're right about this:

> though.  I wonder if there's a better way to do this (e.g., is there a
> refactoring opportunity for getDisplayedLabel?  Should it return an object and
> not a string?).

A few days ago I came across a site that included panels within the page.  Can't recall where now, but I think it was Gmail.  Anyway.... That being the case, it looks like we are going to need most of the functionality that is in default.py's getDisplayedLabel() thus the refactoring you suggest is indeed in order.  I've already done that bit.   Then in Gecko.py we'll grab the label(s) as objects and add additional checks for bogusity as new cases present themselves.

Aaron wrote back to indicate that the change is a bug (phew!). He also indicated that he saw where the issue was and had a fix if I filed the bug.  (woo hoo!)

Filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=379678

Created attachment 87745 [details] [review]
patch to hopefully solve the problem

This patch identifies the unique bogus label scenario in question.  Also, I moved the functionality of default's getDisplayedLabel() into a new findNewLabel() which returns labels as objects.  getDisplayedLabel() calls findNewLabel() to turn the objects into text.

Mike does this solve the problem of all of the combo box contents being spoken when you move focus to them?

Works very nicely.  thanks much 

Patch committed.  Updating bug status to pending.

I think this one is now OK to close.  

Thanks Mike.  Closing as FIXED.