Both <option label> AND <option> content are displayed




Layout: Form Controls
19 years ago
18 years ago


(Reporter: dbaron, Assigned: rods (gone))


({css3, html4, testcase})

css3, html4, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2+][6/15], URL)


(3 attachments)



19 years ago
I think the add() and remove() methods of HTMLSelectElement aren't working.
I'm not sure I'm doing everything right, but it seems they should be working.
I'm more confident about the remove() problems than the add() problems.  The
code is currently at the above URL, but I'm pasting it here too in case it

The debugging code (some of which is commented out with //D) shows that
everything else is working fine (mainly that I have the right select element
and the option element is being created).  The problems are in RemoveAll() and

FILE altsel_nglay_dom.html:


  <TITLE>Alternate Stylesheet Selector Demonstration</TITLE>

  <LINK REL="stylesheet" HREF=""
TITLE="Ultramarine" TYPE="text/css">
  <LINK rel="alternate stylesheet"
HREF="" TITLE="Steely" TYPE="text/css">
  <LINK rel="alternate stylesheet"
HREF="" TITLE="Oldstyle"

  <META http-equiv="Content-Script-Type" content="text/javascript">

  <SCRIPT SRC="altsel_dom.js" TYPE="text/javascript"></SCRIPT>


<BODY onLoad="UpdateSSList(document.getElementById('ssSelector'))">

<!-- can document be omitted here? -->

<h1>Alternate Stylesheet Selector Demo</h1>

 <FORM METHOD="GET" ACTION="dummy.cgi">
  Selected stylesheet:
  <SELECT ID="ssSelector" onChange="selectStyleSheet(this)">
    <OPTION SELECTED>This stylesheet selector requires JavaScript.</OPTION>
  <INPUT TYPE="button" onClick="UpdateSSList(document.getElementById
('ssSelector'))" value="Update">

  <!-- can document be omitted here ? -->



FILE altsel_dom.js:

// copyright (c) 1999  L. David Baron
// based on original by Chris Wilson

function writeout (selector ) { //debug function
	var j;

	for (j=0; j<selector.length; j++) {
		window.alert("selectedIndex is " + selector.selectedIndex);
		window.alert("Option " + j +
			" has text=" + selector.options[j].text +
			", value=" + selector.options[j].value +
			", label=" + selector.options[j].label);

function strISSContains ( str, word ) {
// case-insensitive search for word as one of the space separated values
// within str.
// If word contains spaces, you won't get a match
	var list, i;

	list = str.toLowerCase().split(" ");
	word = word.toLowerCase();

	for ( i = 0 ; i < list.length ; i++ ) {
		// D  window.alert("comparing " + word + " with " + list
[i]);   // D
		if (word == list[i])
			return 1;
	return 0;

function selectStyleSheet( selector ) {
	var i;
 	var title = selector.options[ selector.selectedIndex ].value;

	linkElements = document.getElementsByTagName("LINK");

	for ( i = 0; i < linkElements.length; i++ ) {
		if ( strISSContains(linkElements.title, "stylesheet")) {
			if ( linkElements[ i ].title == title ) {
				linkElements[ i ].disabled = false;
			else if ( linkElements[ i ].title != "" ) {
				linkElements[ i ].disabled = true;

function UpdateSSList( selector ) {

	function RemoveAll () {
		var j;

		for (j=0; j < selector.length; j++ ) {

			window.alert("Removing option " + j);



	function AddIfUnique( ssLink ) {
		var i, opt;

		for ( i = 0; i < selector.length; i++ ) {
			if ( selector.options[i].text == ssLink.title )

		//D window.alert("adding " + ssLink.title);

		opt = document.createElement("OPTION"); // must be uppercase
		// opt.text = ssLink.title;  // THIS (opt.text) IS READONLY
		opt.label = ssLink.title;
		opt.value = ssLink.title;
		// could use document.createTextNode and opt.appendChild  ??

		//D window.alert("ssLink.title=" + ssLink.title);
		//D window.alert("opt.label=" + opt.label);

		// selector.add( opt , selector.options[ selector.length - 1] );
		selector.add( opt , selector.lastChild );
		if ( ! ssLink.disabled )  // only one unique title may be
			selector.selectedIndex = opt.index;

	function AddNone() {

	    var opt;

		opt = document.createElement("OPTION"); // must be uppercase
		opt.text = "--NONE--";
		selector.add( opt , null );
		selector.selectedIndex = 0;

	var j, linkElements;

	// XXX NEEDED selector.options.length = 0; // nonstandard

	linkElements = document.getElementsByTagName("LINK");

	for ( j = 0; j < linkElements.length; j++ ) {   // nonstandard ...
		if ( ( linkElements[ j ].title != "" ) &&
[j].rel, "stylesheet")) ) {
			AddIfUnique( linkElements[j] );
			//D window.alert("adding " + linkElements[j].title);


19 years ago
QA Contact: 4015 → 4078

Comment 1

19 years ago
Further test case at

This test page and the one above show the problems described in 3950, so you
can only hit the buttons once.


19 years ago
Assignee: vidur → pollmann

Comment 2

19 years ago
This ones for you, Eric. Let me know if you need any help.


19 years ago


19 years ago
Target Milestone: M7

Comment 3

19 years ago
See bug 4479


19 years ago
Assignee: pollmann → vidur
Priority: P3 → P2
Summary: HTMLSelectElement add and remove methods not working → CRASH: HTMLSelectElement add method not working
Target Milestone: M7

Comment 4

19 years ago
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!


19 years ago
Target Milestone: M6

Comment 5

19 years ago
Doh! The test should be (nsnull == aBefore), not !-. I'll make a case for this
to go into M6.


19 years ago
Assignee: vidur → pollmann

Comment 6

19 years ago
Checked in a fix so that Add() doesn't crash anymore. Back to you, Eric, to get
the rest of the test to work.


19 years ago

Comment 7

19 years ago
I change the demo slightly so that is uses:

opt = new Option(ssLink.title, ssLink.title)

instead of:


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.


19 years ago
Priority: P2 → P3
Summary: CRASH: HTMLSelectElement add method not working → Option label attribute not used
Target Milestone: M6 → M7

Comment 8

19 years ago
Did I say opt.value?  I meant opt.label.

We're not checking the label attribute when adding an option to the widget, just
the text.  I'll mark this M7.

Comment 9

19 years ago
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.


19 years ago
Summary: Option label attribute not used → Option label attribute not used: GFX Selects

Comment 10

19 years ago
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.

Comment 11

19 years ago
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...

Comment 12

19 years ago
*** Bug 3325 has been marked as a duplicate of this bug. ***

Comment 13

19 years ago
Another test case from 4050:
<form action="">
                <option label="Apple">Apfel
                <option label="Pear">Birne
                <option label="Quince">Quitte

"I would expect the user agent / browser to display the English words, but
instead you just get the German translations."

Comment 14

19 years ago
Redistributing bugs...

Comment 15

19 years ago
Created attachment 813 [details]
simplified test case (as attachment, for convenience)


19 years ago
Whiteboard: [TESTCASE] option label attribute not implemented

Comment 16

19 years ago
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.
Blocks: 7954
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:

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:

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.


19 years ago
Assignee: pollmann → rods

Comment 18

19 years ago
I am resigning this to me, I have a fix for it.


19 years ago

Comment 19

19 years ago
Fixed - Using generated content. If someone uses both a label and the content
you get both and they are appended - So I am leaving this open. We need some CSS
3 functionality to fix this.


19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 20

19 years ago
Forgot to mark fix - if this isn't then attach a SIMPLE test case.
Summary: Option label attribute not used: GFX Selects → Both <option label> AND <option> content are displayed
Whiteboard: [TESTCASE] option label attribute not implemented → [TESTCASE]
rods: You yourself said that you were going to leave this bug open because it
was not fixed -- we are currently showing both the 'label' attribute and the
<option> element content.

We cannot ship as currently implemented. Reopening.

Here is a simple test case:

Comment 22

19 years ago
Yes, you are right, it needs to be reopened.


19 years ago
Resolution: FIXED → ---
Target Milestone: M10 → M11

Comment 23

19 years ago
Clearing FIXED resolution due to reopen.

Comment 24

19 years ago
Changing to M12


19 years ago
Target Milestone: M11 → M12

Comment 25

19 years ago
Changing to M12
Summary: Both <option label> AND <option> content are displayed → {css3} Both <option label> AND <option> content are displayed
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?

Comment 27

18 years ago
*** Bug 16745 has been marked as a duplicate of this bug. ***


18 years ago
Target Milestone: M12 → M14

Comment 28

18 years ago
changed to M14


18 years ago
QA Contact: phillip → gerardok

Comment 29

18 years ago
moving to M15

Comment 30

18 years ago
Created attachment 3983 [details]
Testcase including nested OPTGROUP and OPTION LABEL
Keywords: css3

Comment 31

18 years ago
*** Bug 24130 has been marked as a duplicate of this bug. ***
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase

Comment 33

18 years ago
*** Bug 26216 has been marked as a duplicate of this bug. ***


18 years ago
Summary: {css3} Both <option label> AND <option> content are displayed → Both <option label> AND <option> content are displayed
Whiteboard: [TESTCASE]

Comment 34

18 years ago
mass-move to M16
Target Milestone: M15 → M16

Comment 35

18 years ago
changing milestone to M17 and component to form controls
Component: DOM Level 1 → HTML Form Controls
Target Milestone: M16 → M17

Comment 36

18 years ago
moving to M20
Target Milestone: M17 → M20
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).
Keywords: html4

Comment 39

18 years ago
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>

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:


Both would be fine. But what Mozilla is doing now, rendering both the label attribute -and- the option tag contents, is right out:

     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. 

Comment 40

18 years ago
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

Comment 41

18 years ago
Created attachment 8964 [details]
simple example

Comment 42

18 years ago
Note the additional issue that line layout is not measuring the 
generated content plus the original content correctly. This used to work. That 
is why the horizontal scrollbar is appearing.

Comment 43

18 years ago
The easy way to fix it is to remove the generated content bit that shows the
label, and not support label at all.  That's better than doing what you
currently do, since it won't break pages.

Comment 44

18 years ago
> 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 
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 

Nominating nsbeta2 6/1-. If it doesn't make nsbeta2, it's nsbeta3 stop ship.
Keywords: nsbeta2

Comment 46

18 years ago
I can turn off the part that makes label work with a simple change to html.css

Comment 47

18 years ago
I think that should be done until you can make LABEL and OPTGROUP work
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)
...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)

... 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.

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...
OK, rods, it's unanimous: please go forward with your proposed change. Thx!

Comment 52

18 years ago
I don't understand. I can turn off labels for options and leave labels on for 
optgroups and everything should be fine. It just that labels won't work for 
Right, please do exactly that, rods. I've opened bug 40545, marked FUTURE, to 
track the known bug this will create of LABELs not being implemented for 
OPTIONs. Thanks!

Comment 54

18 years ago
Putting on [nsbeta2+][6/15] radar.
Whiteboard: [nsbeta2+][6/15]


18 years ago
Target Milestone: M20 → M16

Comment 55

18 years ago
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED
VERIFIED on Win2K. This has indeed been fixed for a while now.
You need to log in before you can comment on or make changes to this bug.