792523 - Hung browser: Firefox not setting SELECT option elements text with leading spaces

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[tlhackque]

Attachment: Untitled.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

Clicked on a magic area.


Actual results:

My browser hangs on a website the IE is happy with.


Expected results:

Not a hang.  Here's the real issue.  Javascript onclick decides to add a new option to a select box.  Wanting the text labels to line up, it inspects the existing elements and decides to add some leading spaces.  The code looks like:
  while( foo.option[i].text.length < goal ) {
  foo.option[i].text = " " + foo.option[i].text
 }
This hangs forever, because the space is not added to the text.

(Note that when such labels - in the very same select - are loaded from a CGI, the spaces are preserved.)

Attached are a couple of screenshots showing this.  You can see the stuck look at line 120, the variables, and the dropdown that's the subject of this code.  Notice
that the static values (loaded via HTML, not javascript) have their leading spaces.  But the script is stonewalled when it tries to add to them.

Naturally, the same code works on IE.

This is really bad behavior.  If the field is writable, firefox needs to put the supplied value into the field.    I suppose some folks can argue about what effect this should have on presentation, but as this code shows, not accepting the value can cause reasonable scripts to hang.

Grrh.

Comment 1

[Alice0775 White]

Spec said ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-option-element )

The text IDL attribute, on getting, must return the value of the textContent IDL attribute on the element, with leading and trailing whitespace stripped,

Comment 2

[tlhackque]

Thanks for the pointer.  As usual, other browsers have different ideas.

option . text
Same as textContent, except that spaces are collapsed.

Implies that spaces aren't collapsed in textContent.

But in the interests of harmony, I tried using textContent instead of text.

Same result with FF.  IE doesn't recognize the attribute.  And in any case, when the form initially loads, the options have the leading spaces as shown in the debugger window I attached).  And script reading option.text gets them.  It's only when it tries to add some more spaces that the rule is applied.

This doesn't seem consistent (or sensible).

So we have two challenges:  Compatibility and spec interpretation.  Well, and then there's consistency - why behavior should differ between html & script is mysterious, not to touch the x-browser minefield.

In a testbed I have an ugly workaround where we give up if attempted modification doesn't stick.  But that results in the list elements not being aligned.  At least it doesn't hang.

                     var l = e.options[i].textContent.length;  // FF - discovered issue
		     e.options[i].textContent  = ' ' + e.options[i].textContent;
                     if( l == e.options[i].textContent.length ) break;
 
(It'll go back to .text so IE 'works').

Sigh.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Reading the .text should return a string with no leading space.  And that's what I see here.  So I'm not sure what "And script reading option.text gets them" is about....

I also see .text strip the leading whitespace in every single non-IE browser I have here (Firefox, Chrome, Opera, Safari).

Comment 4

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.