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)
Core
Layout: Form Controls
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.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
The content model contains the whitespace, so the stripping seems to be happening in frames. Passing along to rods.
Assignee: vidur → rods
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
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•24 years ago
|
||
changing to later
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → LATER
Comment 7•24 years ago
|
||
marking open and future
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Target Milestone: M18 → Future
Comment 8•23 years ago
|
||
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•23 years ago
|
||
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.
Updated•22 years ago
|
Priority: P3 → --
Comment 10•22 years ago
|
||
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•22 years ago
|
||
A workaround that works. Replace spaces with \xA0.
Comment 12•22 years ago
|
||
*** Bug 178500 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
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
Comment 14•21 years ago
|
||
*** Bug 202417 has been marked as a duplicate of this bug. ***
Comment 15•21 years ago
|
||
*** Bug 206968 has been marked as a duplicate of this bug. ***
Comment 16•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•18 years ago
|
||
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> What about</option> <option>using &nbsp; to</option> <option>ensure spaces? </option> </select> <script type='text/javascript'> var mysel = document.getElementById('mysel'); mysel.options[3] = new Option(" Three<br>prefix spaces"); mysel.options[3].innerHTML = mysel.options[3].text; </script> Csaba Gabor from Vienna
Comment 20•16 years ago
|
||
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•16 years ago
|
||
It still does NOT WORK for: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9) Gecko/2008052912 Firefox/3.0
Comment 22•16 years ago
|
||
Can you test it with the latest trunk?
Comment 23•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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
Updated•15 years ago
|
Assignee: rods → nobody
QA Contact: desale → general
Comment 27•12 years ago
|
||
(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
Comment 28•12 years ago
|
||
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•12 years ago
|
||
(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 → ---
Comment 30•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
Even in the <select> <option> Aaa bbb </option> </select> case?
Comment 34•12 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #33) > Even in the > > <select> > <option> > Aaa bbb > </option> > </select> > > case? No. Only when is used.
Comment 35•12 years ago
|
||
OK, sounds like we can't just change our whitespace styles, then. I wonder what the hell IE is actually doing there...
Comment 36•6 years ago
|
||
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]
Comment 37•2 years ago
|
||
I'm going to WONTFIX this.
- IE is no longer supported.
- Chrome/Edge behave the same way.
- 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 ago → 2 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•