Closed
Bug 283293
Opened 20 years ago
Closed 20 years ago
Reading innerHTML for a form in JavaScript returns incorrect results for most websites
Categories
(Core :: DOM: Serializers, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 263138
People
(Reporter: rpotencz_nospam, Unassigned)
References
()
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Build Identifier: Firefox 1.0 - Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0 On the website above, reading the innerHTML property of the sign-in form (form name "IOS") returns an empty string. This is apparently due to some nesting of the <table> and <form> tags that the Mozilla HTML parser doesn't seem to recognize. While nesting these tags this way may be bad HTML code, this problem is so common that it makes innerHTML practically useless for forms. This may also occur with other items (not tested). Also, the forms transmit their data correctly when submitted - it's just innerHTML that's broken. Other example pages: https://user03.web.de/Registrierung/benutzerdaten.htm? si=gwR3.1d3Vij.3HhmTe.2T**&mc=hp@fm.freemail@register https://service.gmx.net/de/cgi/nreg?AREA=2&TARIF=0&NT=1 Reproducible: Always Steps to Reproduce: 1. Open any of the mentioned URLs and save it locally. 2. Edit the HTML file and insert onload="alert(document.forms ['IOS'].innerHTML)" (replace IOS with the actual name of the form) into the <body> tag. 3. Open the modified HTML file. Actual Results: An empty string is returned. Sometimes, the result is a part of the form's source code, but incomplete, as in case of the web.de form. Expected Results: innerHTML should return all the HTML code contained between the <form> ... </form> tags.
| Reporter | ||
Updated•20 years ago
|
Comment 1•20 years ago
|
||
Well, this bug is to 99% invalid, the bad nesting causes this (i just can't find a bug to dupe to or to find the invalid html). Mozilla has some code to catch this bad nesting, but it's only code that works so far, that you can submit the forms, etc., but the code is not made for anything else except that.
Comment 2•20 years ago
|
||
Yep. If you look at the DOM, the form has no children. Submit is hacked to work, but that's about as far as it goes.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
| Reporter | ||
Comment 3•20 years ago
|
||
(In reply to comment #2) > Yep. If you look at the DOM, the form has no children. Submit is hacked to > work, but that's about as far as it goes. Of course, in theory, you are right. But, as I said, this makes innerHTML useless for these forms. And since submit works, the webdesigners at fault aren't likely to fix their pages, either. So, from an academical point of view, it's perfectly OK to say "it's not our fault" for this bug. But, in order to make Mozilla work properly in a real world environment, a workaround would be useful. Let me explain my problem: I am currently writing a utility which fills in forms automatically - i.e., the program "reads" the labels next to the edit fields of a form and if it is something like "Name", "Surname", "Address" etc., it fills in the corresponding information. This works pretty well for Internet Explorer already, and now I am working on a Mozilla extension to interface to this program. The program need the source code of the form in order to parse it. Since innerHTML doesn't work properly, I currently have to re-read the page or the frame containing the form using XMLHttpRequest and extract the form's source code from there. This, of course, is an extremely ugly hack and increases the loading times of the affected pages. If there is another more elegant workaround for this problem, I'd be happy to use that instead of innerHTML, but I don't see one at the moment.
Updated•18 years ago
|
Resolution: WONTFIX → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•