Closed
Bug 159282
Opened 22 years ago
Closed 22 years ago
innerHTML erases modified value attributes
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
INVALID
People
(Reporter: bgravi, Assigned: jst)
References
Details
(Keywords: dataloss, Whiteboard: INVALID?)
Attachments
(1 file)
783 bytes,
text/html
|
Details |
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();">
Comment 1•22 years ago
|
||
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
Comment 2•22 years ago
|
||
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
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 ??
Comment 6•22 years ago
|
||
> 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.
Comment 7•22 years ago
|
||
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
Comment 8•22 years ago
|
||
I believe this isn't a bug, but.... Probably your call, jkeiser
Whiteboard: INVALID?
Comment 9•22 years ago
|
||
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
Comment 10•22 years ago
|
||
*** Bug 190452 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
*** Bug 218172 has been marked as a duplicate of this bug. ***
Comment 12•21 years ago
|
||
> 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...).
Comment 13•21 years ago
|
||
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.
Comment 14•20 years ago
|
||
*** Bug 236038 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
*** Bug 242916 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
*** Bug 279641 has been marked as a duplicate of this bug. ***
Comment 17•19 years ago
|
||
*** Bug 284471 has been marked as a duplicate of this bug. ***
Comment 18•18 years ago
|
||
*** Bug 334591 has been marked as a duplicate of this bug. ***
Comment 19•18 years ago
|
||
*** Bug 336748 has been marked as a duplicate of this bug. ***
Updated•11 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•