59248 - [FIX?]<OPTION> values lose embedded spaces

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[dwallace]

<OPTION value="xx  yy"> results in a loss of embedded spaces, in the given case
the two spaces are reduced to one.

the version I'm using:

Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; m18) Gecko/20001105

Comment 1

[Boris Zbarsky [:bzbarsky]]

I see this as well. Confirming bug.

Comment 2

[rods (gone)]

I wonder if we can use white-space: nowrap style for options?

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[John Keiser (jkeiser)]

Attachment: testcase

Comment 5

[John Keiser (jkeiser)]

We're doing this deliberately, in nsHTMLOptionElement::GetText.  We call
CompressWhitespace(), which I assume is what ... well, compresses the whitespace.

bug 30471 would probably benefit from the fix to this.

Comment 6

[John Keiser (jkeiser)]

Assigning to right component.

Comment 7

[rods (gone)]

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

Comment 8

[Sterling Bates]

There's probably a reason why not, but I'll ask anyway: At

http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLOptionEle
ment.cpp#558

why don't we simply remove the call to CompressWhiteSpace?  It would at least 
solve the leading whitespace problem in bug 30471.  Is it because you want to 
trim the trailing whitespace?

Comment 9

[Boris Zbarsky [:bzbarsky]]

See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/content/src/nsHTMLOptionElement.cpp&rev=&cvsroot=/cvsroot&rev=1.59#508
-- hover over the revision number to get a popup telling you what the checkin
comment was....

Looks like it was done for compat with something of some sort; that should
really be the only consideration here, imo.  If we can improve compat with IE in
that code, we should.

Comment 10

[Sterling Bates]

I did some tests and it turns out you already have compatibility in this bug :-
)  This is pretty much fixed AFAICT.  The only gap between the two is when 
adding options via script, which is bug 30471.  Would this indicate that, in 
IE, the HTML parser strips out the whitespace, so that post-parsing options 
aren't affected by it?  (Or am I just making wild guesses here?)

Comment 11

[Boris Zbarsky [:bzbarsky]]

Sterling Bates, are you saying that identical <option> DOM nodes will render
differently in IE?  Any chance of attaching a testcase demonstrating the IE
behavior (with a clear description of the IE behavior in the testcase, since I
have no IE to test with)?

Comment 12

[Sterling Bates]

Attachment: Testcase demonstrating different layouts of similar options

IE renders the two drop downs differently, depending on script vs. HTML
declaration.  Mozilla renders both exactly the same, which falls under the
other bug I refered to.  I'll attach an image comparing IE and Mozilla outputs.

Comment 13

[Sterling Bates]

Attachment: Comparison of IE and Mozilla rendering

Comment 14

[Boris Zbarsky [:bzbarsky]]

In that testcase, do the textnodes inside the <option>s have the same text for
both types of options in IE?

Another possibility is that in Mozilla, when you do |new Option("foo")| that's
equivalent to doing <option>foo</option>.  In IE, it could be equivalent to
<option label="foo"></option>...

For that matter, how does layout of <option label="  aaa"> compare with 
<option>  aaa</option> in IE?

Thanks for your time, Sterling... if we can get a handle on what IE does here
and it it's sane....

Comment 15

[Sterling Bates]

Actually IE doesn't even recognize the label attribute of option.  After 
looking at http://www.blooberry.com/indexdot/html/tagpages/o/option.htm, I 
found that no browser does (as of its last update).

Comment 16

[Boris Zbarsky [:bzbarsky]]

Oh, indeed...  I thought we did, but it looks like bug 4050 was just a bad dream.

So back to my other question.  Are the textnodes in IE identical for the two
<option>s (the one from script and the one not from script)?

Comment 17

[Sterling Bates]

Sorry, missed that one :)  They are identical.

Comment 18

[Boris Zbarsky [:bzbarsky]]

So given two identical DOM nodes IE is rendering them differently?  I'm sorry,
but  I doubt Mozilla will start doing that... :(

If I may ask, how did you compare the textnodes?

Comment 19

[Sterling Bates]

I knew I should've asked you about the textnode thing.  It's been a long day 
(first kid born today), and I didn't give it proper attn.  Are you referring to 
the equivalent of Mozilla's DOM nodes in javascript?  If so, I did not do 
this.  I was just comparing visual rendering.  I'll have to do a more in-depth 
check on this either Saturday night or Sunday.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> Are you referring to the equivalent of Mozilla's DOM nodes in javascript?

Yeah, exactly.  Specifically, I'm talking about things like

  optionObject.firstChild.nodeValue  

(which is the text string in the text text node inside the option that
optionObject points to).  Basically, once the selects are constructed it would
be good to grab corresponding options from the two and compare the nodeValues...
I'll upload a modification of your testcase to that effect.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Attachment: Something like this

I hope IE can handle that... If not, that at least gives a general idea.

Comment 22

[Sterling Bates]

That worked great.  Here's the output:

Value 1: '9 0 1 2', length is 7
Value 2: '    9   0   1   2', length is 17

This reflects exactly what's inside the dropdown: Value 1 is modified, Value 2 
is not.

Comment 23

[Boris Zbarsky [:bzbarsky]]

So the upshot is that IE's parsing of <option> is totally wacky...

I'm not even sure we can do that, in good conscience, since it would break
Composer round-tripping...

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 26

[Emilio Cobos Álvarez (:emilio)]

We force white-space: nowrap on combobox <select>. Maybe we shouldn't.