Closed Bug 265976 Opened 20 years ago Closed 20 years ago

getElementsByTagName works if form is outside a table, not if it is inside

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: kenji, Unassigned)

References

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.51 [en] Build Identifier: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <script language="javascript"> function soWhat() { result = false; var inputElem = document.frm.getElementsByTagName("SELECT"); var name; alert(inputElem[0].value); return result; } </script> </head> <body> <table> <form method="post" action="xxxx" name="frm" onsubmit="return soWhat();"> <tr> <td> <table> <tr> <td> <SELECT name="object"> <option value="x">x</option> <option value="y">y</option> </SELECT> <input type=submit> </td> </tr> </table> </td> </tr> </form> </table> </body> </html> does not work while <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <script language="javascript"> function soWhat() { result = false; var inputElem = document.frm.getElementsByTagName("SELECT"); var name; alert(inputElem[0].value); return result; } </script> </head> <body> <form method="post" action="xxxx" name="frm" onsubmit="return soWhat();"> <table> <tr> <td> <table> <tr> <td> <SELECT name="object"> <option value="x">x</option> <option value="y">y</option> </SELECT> <input type=submit> </td> </tr> </table> </td> </tr> </table> </form> </body> </html> work Reproducible: Always Steps to Reproduce: 1. 2. 3.
I believe this may be due to the html markup being invalid in that form elements aren't allowed where you have them placed in your html.
yeah, the <select> is not actually a child of the <form> in that markup. put the <form>...</form> outside of the <table> and it will work. this is probably invalid.
Yep. Invalid. Please look at the DOM in DOM inspector to see what the parser fixes it up to.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
vrfy.
Status: RESOLVED → VERIFIED
*** Bug 341136 has been marked as a duplicate of this bug. ***
I think this should work as in IE. My understanding was that Firefox direction was to emulate IE's behavior. IE's implementation returns all elements inside the form tag even though it's badly formed. Furthermore, the elements property DOES return select tags and input tags as part of its collection. This is an incosistentcy between elements property and getElementsByTagName function. If elements can see it so should getElementsByTagName. Code written to work for both IE and Firefox will fail for Firefox. Due to this bug it is also impossible to enumerate other tags such as anchor. We develop a program that needs to see anchor tags in the forms. Our application accesses web pages from outside. Meaning that we do not have control over the web pages we access. I think this should be fixed.
> My understanding was that Firefox direction was to emulate IE's behavior. Insofar as this is compatible with the DOM specs and sanity. You do realize that the DOM in IE is not even a tree? There's just NO way we're emulating that. > Furthermore, the elements property DOES return select tags and input tags Yes. The "elements" property is vaguely enough defined that this is a reasonable way for it to behave per DOM spec. And since it's form-specific, it can use out-of-band knowledge that's not part of the DOM. And does. Feel free to try to come up with a fix if you think this should be fixed, but I see no way to do it without violating the DOM specs.
What do the DOM specs say about the form element as it relates to this case? Does the spec say what to do in the case when HTML is not up to standard? I understand that the form tag is not supposed to be inside a table tag. If the DOM spec has to be strictly followed then why does such a page work at all? I am guessing it's for backwards compatibility. If that was the reason then the same logic can be applied to getElementsByTagName. The page works and so should the functions. After all, if you look at the HTML the form tag does indeed have several tags inside of it. We've got a single sign on application (www.passlogix.com) that relies on this (perhaps broken but existing) functionality. We're adding Firefox support. We must also be able to use existing configuration data that was designed for IE. This data may say to look for an anchor in anchors collection at index 2 in a form in forms collection at index 1. With getElementsByTagName returning different data than IE's implementation our aplication fails with Firefox when page is badly formed.
> What do the DOM specs say about the form element as it relates to this case? Nothing specific. The DOM specs simply assume a DOM tree. Please suggest a DOM tree that will: 1) Have the form controls inside the form tag 2) Render the "expected" way when the CSS spec is applied to this DOM tree I strongly urge you to actually inspect the DOM trees that Mozilla and IE produce in this case and see how items 1 and 2 apply to them. Mozilla takes the invalid HTML and produces a DOM that renders the way you expect; given how CSS works this requires that the form controls not be descendants of the form tag. IE does different fixup while parsing (if I recall correctly, the same DOM node ends up in multiple places in the DOM "tree" in IE in this case), then violates the CSS spec (because IE doesn't support the table parts of CSS at all). If you can figure out a DOM tree that satisfies both conditions above, we will be happy to implement it.
I believe I found a workaround. If form element does not have any children then get parent node. Get children of the parent node. Find the form node in the collection and use it as an offset to find an anchor tag by index in the collection.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.