30471 - Spaces not displayed when adding Options to Select box

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, defect)

Description

[Nicholas Cull]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; N; NT4.0; en-US; m14)
BuildID:    2000030308

When using Javascript to add a new option to a select box, any leading spaces in
the displayed text are not preserved. This is different from other browsers
which do preserve this whitespace.

Reproducible: Always

Steps to Reproduce:
1. Open Mozilla
2. Go to the test case I'll attach shortly

Actual Results:
When the onLoad event is fired, both select boxes show a list without any
leading whitespace.

Expected Results:
Leading whitespace should be preserved when displaying the options in a select box.

Additional Information:
There doesn't appear to be a good workaround to this issue. I can't use  
entities, since these show up as text in Mozilla (and in other browsers too).

In this example the whitespace is necessary show a hierarchical display -- in
the select boxes, some items are subordinate to others.

Works Correctly On:
Netscape 4.72, IE 5.01.

Comment 1

[Nicholas Cull]

Attachment: Test case showing options with whitespace not preserved

Comment 2

[vidur (gone)]

The content model contains the whitespace, so the stripping seems to be 
happening in frames. Passing along to rods.

Comment 3

[rods (gone)]

Actually, layout is stripping the white space (ie. yes the frames). In Nav 4.x 
the white is being striped from options in the original html because it went 
through the parser which strippe dit out. The white space wasn't being stripped 
when someone added it via script because it never went thru the parser and and 
the script code for whatever reason didn't bother stripping the whitespace. That 
behavior is definitely a Quirk or even a bug. but I realize some page rely on 
this.

Now, that we are using layout for rendering the select we cannot distinguish 
between options that are added via script and options that aren't. The layout 
system strips the whitespace during layout. I don't see there being quick 
or easy why to fix this with our current appoach. One approach would be to set 
the white-space style attr to "pre" for options added via script. Where and how 
we do that is a mystery.

If spaces are being used to indent the user my want to experiement with 
optgroups.

Setting to M18

Comment 4

[Eric Pollmann]

I agree with Rod.  While it is a shame that it may make a few sites less
attractive, they should really be switching over to using the HTML4 standard,
optgroups, which also (sort of) work in IE 4.x and up:

http://www.w3.org/TR/REC-html40/interact/forms.html#edef-OPTGROUP

Comment 5

[rods (gone)]

changing to later

Comment 6

[Prashant Desale]

Will be fixed later.

Comment 7

[rods (gone)]

marking open and future

Comment 8

[David Anderson]

IMHO, if you can space it with html (via  ), you should be able to space it
with javascript....

Is this related to bug 50348 where the alert dialog takes out 'whitespace'?

Comment 9

[John Keiser (jkeiser)]

Well, maybe this used to happen in layout, but now it's happening in content. 
Specifically nsHTMLOptionElement::GetText is compressing whitespace.

So I we gots a choice to make.  Should the UI preserve whitespace while
JavaScript compresses it, should both compress?  I suspect having JavaScript
preserve whitespace would break some sites, but I can't be sure about this.

To the poster who commented about using optgroups--for many situations they're
great, but if you want a hierarchical menu where you can select the category
itself as well as the options in the category, optgroups just don't work.

Comment 10

[David Anderson]

Responding to comment #1> There doesn't appear to be a good workaround to this
issue :

a workaround is posted at
http://mason.gmu.edu/~danders2/addEditLibraryWorkaround.html

Comment 11

[Timothy C. Quinn]

Attachment: Another report for same bug with \xA0 workaround

A workaround that works. Replace spaces with \xA0.

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** Bug 178500 has been marked as a duplicate of this bug. ***

Comment 13

[Phil Schwartau]

Resummarizing per bug 178500:

from "Leading spaces not displayed when adding Options to Select box"
  to "Spaces not displayed when adding Options to Select box"

Comment 14

[Phil Schwartau]

*** Bug 202417 has been marked as a duplicate of this bug. ***

Comment 15

[Phil Schwartau]

*** Bug 206968 has been marked as a duplicate of this bug. ***

Comment 16

[Marc Bauer]

why will this bug not fixed? future is realy far far away... looks like 
minimum 1 year. very unlikely. i have used the workaround to fix this, but i 
don't like such fixes... only for gecko based browsers. every other browser 
works fine without this change.

Comment 17

[Phil Schwartau]

cc'ing jst: would this be hard to fix? Note that some websites
use spaces to create a tree-like appearance in a <select>:

XXXXXX
  aaaaaa
     bbbbbb
     cccccc
YYYYYY

And Mozilla just flattens it out:

XXXXXX
aaaaaa
bbbbbb
cccccc
YYYYYY

Comment 18

[Marc Bauer]

i'm realy not a JavaScript progger - and therefor it might be difficult to 
fix :-). We are using spacesfor a tree view... and mozilla will trim this 
spaces... and yes - this is a problem!

Comment 19

[Csaba Gabor]

The following method inserts multiple leading/trailing/in between spaces on my WinXP Pro's FireFox 1.5.0.9.  Use .innerHTML on existing option elements.  This method won't work for alerts as in bug 50348, though.

<select size=4 id=mysel>
<option>&nbsp;&nbsp;What&nbsp;&nbsp;&nbsp;about</option>
<option>using &amp;nbsp; to</option>
<option>ensure&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        &nbsp;&nbsp;spaces?&nbsp;&nbsp;&nbsp;&nbsp;</option>
</select>
<script type='text/javascript'>
  var mysel = document.getElementById('mysel');
  mysel.options[3] = new Option("&nbsp;&nbsp;&nbsp;Three<br>prefix spaces");
  mysel.options[3].innerHTML = mysel.options[3].text;
</script>

Csaba Gabor from Vienna

Comment 20

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

It works for me now with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062103 Minefield/3.1a1pre

What about other platforms and Seamonkey?

Comment 21

[Tilmann Bubeck]

It still does NOT WORK for:

Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008052912 Firefox/3.0

Comment 22

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Can you test it with the latest trunk?

Comment 23

[Tilmann Bubeck]

It does NOT WORK with firefox, taken from nightly-builds.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1pre) Gecko/2008062204 GranParadiso/3.0.1pre

Gecko 1.9.0.1pre does not seen to implement it, but 1.9.1a1pre does. Where could I get firefox with gecko 1.9.1a1pre?

Comment 24

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

( google next time ;-) )

Remember to test the bug in safe mode or with a blank profile. It's better if you also disable temporarily all plug-ins.

Comment 25

[Tilmann Bubeck]

Unfortunately: still no spaces with 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre) Gecko/2008062302 Minefield/3.1a1pre

downloaded from the above link.

Comment 26

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Mh, it's strange, I retested this bug and now I can reproduce it. Probably I didn't understand it well, I don't remember. Anyway now it's confirmed also for Linux. 

Can someone confirm it also for Mac?

Comment 27

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to John Keiser (jkeiser) from comment #9)
> Well, maybe this used to happen in layout, but now it's happening in
> content. 
> Specifically nsHTMLOptionElement::GetText is compressing whitespace.

This is required by the HTML spec.

If nsListControlFrame::GetOptionText shouldn't compress whitespace, it should use GetAttr directly. -> Layout.

Comment 28

[Boris Zbarsky [:bzbarsky]]

This bug needs a testcase.  The original testcase here is rendered identically by WebKit and Gecko and Presto as far as I can tell, so if it's meant to show the bug either it's failing or WebKit and Presto have the same behavior we do.

Comment 29

[Mounir Lamouri (:mounir)]

(In reply to Boris Zbarsky (:bz) from comment #28)
> This bug needs a testcase.  The original testcase here is rendered
> identically by WebKit and Gecko and Presto as far as I can tell, so if it's
> meant to show the bug either it's failing or WebKit and Presto have the same
> behavior we do.

Indeed. But it's reproducible with IE9 and IE10 PP2 so I guess it's kind of a legacy behavior nobody has except IE.
I wonder how safe it would be to try to fix that?

Comment 30

[Boris Zbarsky [:bzbarsky]]

Mounir, is it only reproducible for options added via script?  Or does IE also preserve the whitespace for options coming from the parser?

Comment 31

[Boris Zbarsky [:bzbarsky]]

Also, does IE only preserve leading/trailing whitespace, or also other whitespace (e.g. if you have an option value like "foo     bar")?

Comment 32

[Mounir Lamouri (:mounir)]

(In reply to Boris Zbarsky (:bz) from comment #30)
> Mounir, is it only reproducible for options added via script?  Or does IE
> also preserve the whitespace for options coming from the parser?

Also from parser.

(In reply to Boris Zbarsky (:bz) from comment #31)
> Also, does IE only preserve leading/trailing whitespace, or also other
> whitespace (e.g. if you have an option value like "foo     bar")?

Wherever the whitespaces are, they are preserved.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Even in the

  <select>
    <option>
      Aaa  bbb
    </option>
  </select>

case?

Comment 34

[Mounir Lamouri (:mounir)]

(In reply to Boris Zbarsky (:bz) from comment #33)
> Even in the
> 
>   <select>
>     <option>
>       Aaa  bbb
>     </option>
>   </select>
> 
> case?

No. Only when &nbsp; is used.

Comment 35

[Boris Zbarsky [:bzbarsky]]

OK, sounds like we can't just change our whitespace styles, then.  I wonder what the hell IE is actually doing there...

Comment 36

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 37

[Mike Kaply [:mkaply]]

I'm going to WONTFIX this.

1. IE is no longer supported.
2. Chrome/Edge behave the same way.
3. IE mode in Edge behaves the same way (indicating this behavior was changed in IE).

So all browsers have the same behavior.