341136 - getElementsByTagName does not return children of form in badly formed table HTML

Status: RESOLVED DUPLICATE of bug 265976

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

Description

[Michail Frolov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Using getElementsByTagName('*') to obtain contained objects in the forms of the HTML page accessed by going to the supplied URL returns a collection with zero elements.

It appears the HTML on the page is badly formed.  However the page is displayed properly and functions properly.

IE is capable of retrieving contained objects of the forms on the same page.


Reproducible: Always

Steps to Reproduce:
Attempt to use getElementsByTagName('*') to obtain objects in any of the forms in the supplied URL.
Actual Results:  
A collection of zero elements is returned.

Expected Results:  
A collection of the elements contained inside the <form></form> tags.

Comment 1

[Jesse Ruderman]

How does this bug affect http://www.chase.com/ccp/index.jsp?pg_name=ccpmapp/card_servicing/account_access/page/CCSMktPayBill?

Do you have a small testcase you can attach to this bug?  

Comment 2

[Michail Frolov]

Forst, I need to make an adjustment to the original description.

The <form></form? is actually empty on the page.

However, when 'input', 'select' and 'a' tags are enumerated by using getElementsByTagName on each form the results vary between IE and Firefox.

IE actually returns input and anchor elements for the forms while Firefox does not.

This problem has no effect on the supplied web page.  It affects the application that we develop that needs to consistently enumerate tags using IE and Firefox.


I am trying to create a small testcase but so far I cannot make the locally saved web page work.  The events seem to not function in a local copy.  Any ideas why a local copy would behave differently?

Comment 3

[Jesse Ruderman]

What events?  Maybe you'll need to make a reduced testcase for that issue too ;)

Comment 4

[Michail Frolov]

Attachment: A testcase to demonstrate discrepancies in getElementsByTagName between IE and Firefox

Comment 5

[Michail Frolov]

Found out why the saved page was not working.

It looks like Firefox saves a generated web page rather than the original one.  The generated page rearranged the tags the way it liked.  As a result form tags became empty.

So, the original description of the problem stands correct.

I was able to create a small test case.  View the attached HTML in IE and Firefox.  You will see the differences in the values returned by getElementsByTagName.

Comment 6

[Michail Frolov]

Attachment: A testcase to demonstrate discrepancies in getElementsByTagName between IE and Firefox

This test case also demonstrates that "elements" property works correctly in both browsers.

Comment 7

[Jesse Ruderman]

Looks like a dup of bug 265976.  It's easy enough to work around -- put the form elements inside the table cells, and use CSS to either turn off their margins or make them inline.  Or keep the HTML invalid and get the input elements by ID instead of off of their forms.

*** This bug has been marked as a duplicate of 265976 ***

Comment 8

[Michail Frolov]

This is not easy to work around.  I am attempting to enumerate tags in a web pages that do not belong to me.  I have no control over web pages' source.

It's actually impossible to obtain all anchor tags inside a form due to this bug.

Comment 9

[Jesse Ruderman]

To be able to suggest a better workaround, I'd need to know what kinds of pages are involved and why you're interested in anchor tags "inside" the forms.

Comment 10

[Michail Frolov]

We have a single sign on application.  It originally supported only IE but we've decided to add support for Firefox.  Since all of our configuration data relied on IE's functionality, it was implemented based on that.

Since we have existing users the existing configuration data must continue to work.

For example, we store "controls" (username, password, submit) based on their names or, in the absense of names, index of the controls.  The indexes are relative to the forms the "controls" are located in.  In this case "controls" are tags.

The data may indicate that the "submit" control is an anchor tag located in anchor tags collection at index 2 in forms collection at index 1.  When neccessary, our application finds that tag and "clicks" on it.

With this bug this data is invalid and our application fails.

Comment 11

[Jesse Ruderman]

So the reason you care about the exact DOM generated from this invalid HTML is because you want to work around another misuse of HTML, using anchor tags as submit buttons?  I have to admit that I'm amused.

Comment 12

[Michail Frolov]

Unfortunately the web pages are not under our control.  From the end user's perspective they do not have a problem because they work.  Still, I found a workaround.  See bug that this bug is a duplicate of for details.