Closed Bug 30471 Opened 24 years ago Closed 2 years ago

Spaces not displayed when adding Options to Select box

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: run2000, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: parity-ie, polish)

Attachments

(2 files)

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.
The content model contains the whitespace, so the stripping seems to be 
happening in frames. Passing along to rods.
Assignee: vidur → rods
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
Status: NEW → ASSIGNED
Target Milestone: M18
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
changing to later
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → LATER
Will be fixed later.
Status: RESOLVED → VERIFIED
marking open and future
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Target Milestone: M18 → Future
Keywords: dom0
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'?
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.
Priority: P3 → --
Depends on: 59248
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
A workaround that works. Replace spaces with \xA0.
*** Bug 178500 has been marked as a duplicate of this bug. ***
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"
Summary: Leading spaces not displayed when adding Options to Select box → Spaces not displayed when adding Options to Select box
*** Bug 202417 has been marked as a duplicate of this bug. ***
*** Bug 206968 has been marked as a duplicate of this bug. ***
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.
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
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!
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
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?
It still does NOT WORK for:

Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008052912 Firefox/3.0
Can you test it with the latest trunk?
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?
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.
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.
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?
Keywords: polish
OS: Windows NT → All
Assignee: rods → nobody
QA Contact: desale → general
(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.
Status: REOPENED → NEW
Component: DOM: Core & HTML → Layout: Form Controls
Keywords: dom0
QA Contact: general → layout.form-controls
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.
(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?
Hardware: x86 → All
Whiteboard: [parity-ie]
Target Milestone: Future → ---
Mounir, is it only reproducible for options added via script?  Or does IE also preserve the whitespace for options coming from the parser?
Also, does IE only preserve leading/trailing whitespace, or also other whitespace (e.g. if you have an option value like "foo     bar")?
(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.
Even in the

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

case?
(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.
OK, sounds like we can't just change our whitespace styles, then.  I wonder what the hell IE is actually doing there...
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-ie
Whiteboard: [parity-ie]

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.

Status: NEW → RESOLVED
Closed: 24 years ago2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: