Closed Bug 159282 Opened 22 years ago Closed 22 years ago

innerHTML erases modified value attributes

Categories

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

defect
Not set
critical

Tracking

()

RESOLVED INVALID

People

(Reporter: bgravi, Assigned: jst)

References

Details

(Keywords: dataloss, Whiteboard: INVALID?)

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 
1.0.3705)
BuildID:    6.2

The HtmlElement.innerHTML property does not behave properly. It gives a static 
html when called.
For e.g, if I have the following code:
<div id="testDivHtml">
	<input type="text" id="testinput" value=""> <br>
	<input type="button" value="View Html" onclick="showHtml();">
</div>
function showHtml()
{
	alert( document.getElementById("testDivHtml").innerHTML );
}

and then when I enter some data in the text and click the button, the data 
entered in the text box is not available in the innerHTML returned. The same 
property in IE6.0 returns the innerHTML with the data entered. 


Reproducible: Always
Steps to Reproduce:
1. Add the following code in a html page
<div id="testDivHtml">
	<input type="text" id="testinput" value=""> <br>
	<input type="button" value="View Html" onclick="showHtml();">
</div>
<script>
function showHtml()
{
	alert( document.getElementById("testDivHtml").innerHTML );
}

</script>
2. open the html page, and add some text in the text box, say "testing"
3.click the button, and see the innerHTML, you will see that the data entered 
in the text box does not show up. 

Actual Results:  The data entered in the text box does not show up. Only the 
data present when the page was rendered is shown.
	<input type="text" id="testinput" value=""> <br>
	<input type="button" value="View Html" onclick="showHtml();">

Expected Results:  It should have parsed and picked up the data entered in the 
text box, like the following
	<input type="text" id="testinput" value="testing"> <br>
	<input type="button" value="View Html" onclick="showHtml();">
IE has a known bug in which the "value" attribute reflects the "value" DOM
property.  That should not be the case, in fact...  I suspect that that is the
root of the problem here.
Status: UNCONFIRMED → NEW
Component: DOM HTML → DOM Mozilla Extensions
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
If I have a form that has dynamically added fields, my form input gets erased
every time a new element is added.  Should a call to innerHTML+= really
overwrite the current DOM values with the original HTML values.  It seems to me
that in this case, IE's behavior really isn't a bug, but a feature.  innerHTML+=
becomes annoying and nearly useless with respect to dynamic forms.  Right now in
Mozilla, it seems that the easiest, but cludgy, way to work around this is to
traverse all form elements inside the affected object, call something like
document.myform.myelement.setAttribute('value',document.form.myelement.value),
and then call innerHTML+=.  Since innerHTML isn't part of the standard, then we
should probably just do what IE does and copy all .value's to all corresponding
'value' attributes.
Keywords: dataloss
Summary: innerHTML function behavior incorrect !! → innerHTML erases modified value attributes
Attached file sample testcase
I found Similar bug (same??) Bug today.
I am porting app that works on IE to work with Mozilla.
It copies a form from one place to another using innerHTML.
In IE the current values of the tickboxes are kept but they are
not kept by mozilla.

I attach a simplified testcase to show this.
When first loaded the tickbox is unchecked. If you tick it normally
or with the button provided and then click on 'copyDiv' the value
is lost when the div is copied.
Dont understand the difference between 
the "value" attribute 
and the "value" DOM property

IF I change my tickBox code from

function tickTheBox()
{
var checkBox = document.getElementById('testBox');
checkBox.checked = true;
}

to

function tickTheBox()
{
var checkBox = document.getElementById('testBox');
checkBox.setAttribute('checked',1);
}

Then the tickbox is still ticked but the value is
copied by innerHTML.

Also I notice that in IE
checkBox.setAttribute('checked',0);
will untick a box but Mozilla requires removeAttibute
Do you think thats a bug in IE ??
> Dont understand the difference between  the "value" attribute 
> and the "value" DOM property

The "value" attribute corresponds to the defaultValue DOM property.  This is 
the value initially set on the control.  This is what the control gets reset to 
if the user clicks the "reset" button in the form.  The value DOM property is 
the current value of the control -- this is what changes as the user types in 
the control.

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
I believe this isn't a bug, but....

Probably your call, jkeiser
Whiteboard: INVALID?
Yes, invalid.  The central problem here is the IE, against the spec, sets the
"value" attribute when you set .value.  Attributes are copied when you copy
innerHTML; therefore the value attribute (and the checked attribute) are copied
in the innerHTML copy.

The spec explicitly states otherwise, even though it seems stranger every day:

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485

We follow the spec.  Also note bug 184732, which is about changing this behavior
somewhat but *will not* fix this problem because we have this thing in Mozilla
for following specs as much as possible.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
*** Bug 190452 has been marked as a duplicate of this bug. ***
*** Bug 218172 has been marked as a duplicate of this bug. ***
> We follow the spec.  Also note bug 184732, which is about changing this behavior
> somewhat but *will not* fix this problem because we have this thing in Mozilla
> for following specs as much as possible.

funny because last time I checked .innerHTML was not even part of the spec. It
seems to be that if you are going to implement it, then it should be implemented
in the same way as it is in "other browsers" (98% or so percent of them...).

Chris, innerHTML is implemented the same way in Mozilla and IE -- it serializes
the elements and their attributes.  The issue is that the "value" attribute in
IE is _changed_ when you type in the form control.  It should not be.  Try it:
create a form control, then type in it, then see what getAttribute("value")
returns on that form control in Mozilla and IE.

So innerHTML is the string representation of the DOM involved in both browsers;
it's just that IE reflects the current form control state in the DOM, which is a
big no-no per the DOM spec.
*** Bug 236038 has been marked as a duplicate of this bug. ***
*** Bug 242916 has been marked as a duplicate of this bug. ***
*** Bug 279641 has been marked as a duplicate of this bug. ***
*** Bug 284471 has been marked as a duplicate of this bug. ***
*** Bug 334591 has been marked as a duplicate of this bug. ***
*** Bug 336748 has been marked as a duplicate of this bug. ***
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: