433544 - textbox does not report correct value

Status: NEW

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

Description

[Godmar Back]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

A textbox XUL element in a toolbar does not report a "value" entered by the user. Instead, the value property has the value "". 

The textbox itself is created as a result of a call to cloneNode(true) on an anchestor. Subsequently, the original textbox reports the correct value, but the clone does not report the correct value.

The code works correctly in FF 2.0.0.14. It breaks in FF 3.0b5.  

Interestingly, the "textContent" property has the same (wrong) value as the "value" property, but the "textLength" property shows the correct number of characters.

Please study the screenshot attached. The two textboxes in question contain the values "malaria" and "management", respectively. The textbox at the bottom with the value "management" is the one that was created via cloneNode(true).  This one is selected in the DOM inspector. Observe the values of the properties "textContent", "textLength", and "value" on the right.



Reproducible: Always

Steps to Reproduce:
1.Install libx.org/editions/vt.5/libx-vt.xpi
2.Enter anything into Keyword, then press blue down button
3.Enter anything into "Title", then press Enter or "Search Addison"
Actual Results:  
It will search for the Keyword only --- because it thinks the user didn't enter anything into the Title field (its value is reported to be "", see above)

Expected Results:  
It should report the value the user entered.

Should I just not use "cloneNode"????

Comment 1

[Godmar Back]

Attachment: Screenshot showing wrong value in DOM Inspector

Comment 2

[Ria Klaassen (not reading all bugmail)]

Confirmed on Windows XP. Regression range is:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-04-14+18%3A00&maxdate=2006-04-15+05%3A00
Caused by Bug 333942 ?

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It would be great with a minimal testcase here. If bug 333942 really did cause this (which seems unlikely, but not impossible) it's probably due to some random other XUL code depending on some bug in DOM-Core.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Also, the textContent value should be "". It's the concatenation of all text children of the element, which of course there aren't any. Not sure what textLength is though.

Comment 5

[Godmar Back]

My mistake on textContent.

textLength is the number of characters entered, here: "management" -> 10. If I enter something else, textLength will change to reflect however many characters I've entered. But .value remains "".

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Again, a minimal testcase here would be great.

cloneNode does behave very odd when it comes to XBL, so that's likely the culprit. But I don't see anything in that regression range that should have affected that.

Comment 7

[Godmar Back]

Not sure how to make the test case smaller or how to extract a test case from
the code.

The relevant line where the wrong value arrives is
http://libx.org/libx/src/base/chrome/libx/content/libx/libx.js
in function "extractSearchFields".  There's a commented out 
//alert(f.firstChild.value + " " + f.firstChild.label + " " +
f.firstChild.nextSibling.firstChild.value);

The expression f.firstChild.nextSibling.firstChild refers to the textbox whose
value is wrong.

My gut feeling is that it's related to the cloning process. The value property
also is not retrieved for all other clones, nor is it for clones of clones.
Only the original source acts correctly.

[On an unrelated note, we've had trouble with cloneNode before. For instance,
cloning a menu item doesn't appear to clone its value and label.]

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Just create a XUL file that can be opened normally in the browser?

Comment 9

[Godmar Back]

Sorry, the time involved in that (and accurately replicating the rather complex cloning setup) is for us better invested in cutting out the clone approach. We'll file a new bug if the issue persist then still.

BTW, if I were set up to debug Mozilla, I'd simply fire a build in which it breaks and use gdb to examine the state at the point where "value" reports the wrong value. I don't think a smaller test case is truly needed here.

 - Godmar

Comment 10

[Surya Ismail]

Attachment: Minimal testcase

To test, load the page, enter some values in the textboxes and click. If you comment out 'newElem.firstChild.value = "";' in onLoad, it works fine. So the problem doesn't seem to be the clone itself. It's more in setting the value before appending it.

For the libx application, in http://libx.org/libx/src/base/chrome/libx/content/libx/libx.ff.js, in the libxEnv.ff.addSearchField, removing or moving 'newSearchField.firstChild.nextSibling.firstChild.value = "";' ought to fix things.

Comment 11

[Godmar Back]

Using .setAttribute("value", "") instead of setting the value property directly appears to work in FF 3.0b5; however, this may be redundant or unrelated because the old value doesn't appear in the textbox in FF3.0 even without this setAttribute call.  The documentation states that the "value" attribute relates to the default value of a textbox; it's not clear when that default value is used in the case of cloned textboxes.

Consider this testcase: http://top.cs.vt.edu/~gback/ie8/clonebug.xul

It shows that "clone" does not clone a textbox's current value, nor does it respect if the textbox's default value is subsequently set via setAttribute().

What is the specification for cloning with respect to properties such as value and for attributes such as "value"?

Comment 12

[nikolaenikolajj]

Attachment: testcase : set textbox values bu 3 different ways and see result

1) Press first on button "addField", new textbox is created
2) press many times on button "setFieldVal" each time value of textbox wil be set different ways ( setAttribute, .value=, ['value']= ) and result every time is ditterenf.

Another test : comment line "tb.setAttribute("value", "aaa");" and uncoment line "tb.value="ee"; so initial value of textbox vill be set another way.
Now repeat steps 1)2) - it behaves agin wrong, but now it's another wrong way :)

Comment 13

[nikolaenikolajj]

In addition to previous comment : I have forgotten to say that output goes to console, so XUL file must be placed somewhere in an extention folder. Than the output result will be seen in console each time you press "setFieldVal" button

Comment 14

[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.