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
Last Resolved: 19 years ago
Resolution: --- → LATER
Will be fixed later.
Status: RESOLVED → VERIFIED
marking open and future
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Target Milestone: M18 → Future
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
Created attachment 105096 [details] Another report for same bug with \xA0 workaround 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
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:184.108.40.206pre) Gecko/2008062204 GranParadiso/3.0.1pre Gecko 220.127.116.11pre 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?
OS: Windows NT → All
(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
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
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 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.)
You need to log in before you can comment on or make changes to this bug.