This page is a crasher.
In nsHTMLSelectElement::Add ya' check to see if aBefore is null. If it is null,
it is then immediately dereferenced it to get at it's parent, which of course
causes a crash. :)
Can you take a look since it's your baby? Thanks!

I change the demo slightly so that is uses:
opt = new Option(ssLink.title, ssLink.title)
instead of:
opt=document.createElement("OPTION");
opt.label=ssLink.title;
opt.value=ssLink.title;
And it seems to work okay (aside from bug 3322 making it look broken)
I'm looking into why setting value with opt.value = xxx doesn't seem to work.

I think you should only support label if you support OPTGROUPS. Do you support
OPTGROUPS? (Or something like that...)
Note that the script may be wrong. It was my first attempt at doing anything
with the DOM. I now know the correct way to change/create the content of the
Option element, which is probably the better way to do this.

Optgroups are currently supported (using indention) in GFX rendered selects, but
not native selects. This could change.
I agree with what you said. The example in the spec makes this more clear -
using label while not supporting optgroups might lead to incorrect rendering of
selects with optgroups in them.
However, the argument above is weakened by the definition of the label attribute
of an option, which makes no provision for whether to change the rendering if
the option is in an optgroup or not:
label = text [CS]
This attribute allows authors to specify a shorter label for an option
than the content of the OPTION element. When specified, user agents should
use the value of this attribute rather than the content of the OPTION
element as the option label.

I think the assumption in that statement is that one is supporting OPTGROUPs.
This was added to HTML 4.0 so that HTML 4.0 browsers will use the shorter
labels, since they support OPTGROUPs. The spec didn't explain what to do about
partial support. At least that's the way I see it...

Another test case from 4050:
<form action="mailto:Kligor.T@gee.whiz.com">
<select>
<option label="Apple">Apfel
<option label="Pear">Birne
<option label="Quince">Quitte
</select>
</form>
"I would expect the user agent / browser to display the English words, but
instead you just get the German translations."

Overview Description:
if you have <OPTION label="xxx">yyy, yyy is displayed in the pull-down, not xxx.
If yyy is empty, consequently nothing is displayed in the pull-down.
Steps to Reproduce:
1) Load the attachment (id=813)
2) you see a pull down menu with three entries
Actual Results:
the three entries are X, Y and Z
Expected Results:
the three entries should be A, B, and C, as these are the label attributes of
the <OPTION> tags.
Build Date & Platform Bug Found:
M7 & 1999071108 build (Win32)
Additional information:
label attribute is completely ignored. <OPTION label="xxx"></OPTION> is rendered
as empty entry.

FWIW, I would tend to go with the train of thought that says that when we
support OPTGROUP (i.e., with GFX widgets) then we should use the label
attribute for the caption, and when we don't (i.e., native widgets) then we
should use the content of the OPTION elements.
There is an OPTGROUP test case here:
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/optgroup.shtml
Note that if we are in drop-down mode, we should always use the long form
(content of the OPTION element) as the content of the combo box's edit box.
See the example in the spec:
http://www.w3.org/TR/REC-html40/images/optgroup_exmpl.gif
The reasoning behind this is that the content of the OPTION element contains
the equivalent of the label of the OPTGROUP _and_ the label of the OPTION.

Since we are pending on CSS3 functionality (namely, 'content' everywhere)
I am marking this {css3}. However, we need to set a dependency. Is there an
RFE covering CSS3's proposed extension to the 'content' property?

Please correct me if I misunderstand: the net net is that if we don't fix this
bug, in effect, the LABEL attribute on OPTGROUP won't be supported for FCS, and
content developers will have to put what they want displayed into the content of
the tag.
Obviously, this would be unfortunate. However, if content developers had
alternate text they would *prefer* to be displayed, they could go ahead and put
that in the LABEL. Moz/N6 FCS would ignore the LABEL attribute value. But when
this bug was fixed in a subsequent point release, that problem would disappear.
Ian, could you explain why you marked this css3 rather than html4?

We HAVE to fix this if we support OPTGROUPs. The "label" attribute and the
OPTGROUP element go hand in hand; support for one but not the other would be
a serious pain in the neck for content developers.
And it is marked HTML4: that's what the bug 7954 dependency is. Adding html4
keyword (which didn't exist last time I visited this bug).

I don't understand ekrock's comment, but it's really pretty simple. Take markup like:
<optgroup label="Netscape">
<option label="4.x">Netscape 4.x</option>
<option label="3.x">Netscape 3.x</option>
</optgroup>
Browsers which don't recognize the optgroup element and label attribute would just use the contents of the option tags. The list box would read:
Netscape 4.x
Netscape 3.x
Browsers that understand optgroup and the label attribute could render the list box more nicely as:
-Netscape-
4.x
3.x
Both would be fine. But what Mozilla is doing now, rendering both the label attribute -and- the option tag contents, is right out:
-Netscape-
4.xNetscape 4.x
3.xNetscape 3.x
The net effect if we don't fix this is that properly written pages will look just plain wrong. Not fixing this isn't reasonable.
If for some reason this is too complicated, then perhaps Mozilla could ignore the label attribute entirely, and degrade gracefully to the first example above.

non, no, no. This bug is for whenyou have an option specified as:
<OPTION label="mylabel" value="myvalue">mycontent</option>
The option would display as: "mylabelmyoption"
The issue is, we use generated content for displaying the contents of the label
attr when it exists. The problem with this bug is when an author specifies BOTH
the label and some content (between the the start/end tags) both are displayed.
Why HTML 4.x specifies a label for options is beyond me because it is redudant.
I keep pushing this bug off because it is really really hard to fix and the
pay-off is sooooooo small. Label

> Why HTML 4.x specifies a label for options is beyond me because it is redudant.
The HTML 4 specification reads "When rendering a menu choice, user agents should use the value of the label attribute of the OPTION element as the choice. If this attribute is not specified, user agents should use the contents of the OPTION element."
It seems to me that the intention is for user agents that support earlier versions of HTML continue to display the contents of the OPTION element, while HTML 4.0 compliant user agents (which presumably render OPTGROUP) can display a less verbose label="..." attribute instead.

OK, thanks to all for explaining to me the meaning of this bug. Clearly
displaying both the label and the content is wrong (and worse, makes it
difficult for content developers to use label at all in their content so long as
browsers with this bug exist in the market--this is a classic example of a
situation where the presence of a bug in a given browser would render that
standard feature virtually unusable for everyone). For FCS, we must clearly do
one of the following:
1) (preferable) per the spec, use label if it exists, and content if there is no
label
2) (if we don't have the development cycles to do #1) not support label and
document this as a known bug in the release notes; given engineering's LOE
assessment of this as "really really hard," this is likely what we'll have to
accept
Nominating nsbeta2 6/1-. If it doesn't make nsbeta2, it's nsbeta3 stop ship.

If you turn off LABEL support you really should turn off OPTGROUP support as
well. Otherwise the forms end up looking only a little less silly than now:
-Netscape- (optgroup but not label)
Netscape 4.x
Netscape 3.x
...instead of:
-Netscape- (optgroup and label)
4.x
3.x
...or just:
Netscape 4.x (neither optgroup nor label)
Netscape 3.x

For once, I disagree 100% with Ian. ;-> Here's why: it's true that in an ideal
world it would look like this:
-Netscape- (optgroup with concise label)
4.x
3.x
... but it seems that we're not going to get label in, so that's out. Then the
question is: "Given that, how can we provide the closest adherence to the
intended functionality and enable web designers to use as much of the intended
functionality as possible?"
It's true that having -Netscape- (for example) as the optgroup divider and also
having the same non-abbreviated text in the option is less than ideal, but at
least it allows the content developer to (if he or she wishes) structure long
option lists into logical groups. Maybe the text of those groups doesn't look
quite as concise as we'd wish, but at least the logical and visual grouping is
preserved, and web designers can (if they wish) even put the LABELs they'd
really like into the content, so that when this bug is fixed, it will work
precisely as desired on newer versions.
-Netscape- (optgroup but not label)
Netscape 4.x
Netscape 3.x
If we restrict designers to using neither label nor optgroups, we've denied them
both the concise labels *and* (unnecessarily) the ability to create visiual,
logical groupings, and have limited the first release to flat, unstructured
lists, holding back the increasing structuring of content on the web.
Netscape 4.x (neither optgroup nor label)
Netscape 3.x
My take: (1) it sounds like full support for option label is too hard for FCS,
alas, but (2) we can easily ignore the option label and display the content
only, so we should do that, and (3) we can preserve the ability (which is
already working in the code) to structure the lists into groups.

*ponder*
Actually, yes, you're right (Eric). Providing the grouping of OPTGROUP is worth
the minor inconveniance of redundancy in the labelling.
So as David said, we should, for now, remove the bit in html.css which displays
the label. We can revisit this post FCS. That makes it a very easy fix, BTW,
and therefore easy to land by nsbeta2...