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)

x86
Windows 2000
defect
Not set
major

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.
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.
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
(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.
Resolution: WONTFIX → DUPLICATE
You need to log in before you can comment on or make changes to this bug.