49951 - form.elements[] ordered differently than 4.x

Status: VERIFIED FIXED

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

Description

[steve]

From Bugzilla Helper:
User-Agent: Mozilla/4.74 [en] (WinNT; U)
BuildID:    2000080712

In the attached block of completely invalid HTML, The form.elements[] array has 
the elements in a different order than current browsers (IE 5.5 and NS 4.74 at 
least).


Reproducible: Always
Steps to Reproduce:
View the attached HTML file.  Hit submit.  The iterate() function shows you the 
contents of the elements[] array.

Actual Results:  In mozilla, the elements[] array is in this order:
second
third
first
fourth

Expected Results:  I believe the elements[] array should be in source-code 
order:
first
second
third
fourth


This breaks form validation functions that address given elements of a form by 
their index in the elements[] array.  It works fine if you swap the </table> and 
</form> in that chunk of HTML making it more valid.  Are you going to tell me to 
go away and it's my fault for using invalid HTML?

Comment 1

[steve]

Attachment: Demonstrates strange ordering of elements[]

Comment 2

[Asa Dotzler [:asa]]

setting bug status to New

Comment 3

[Johnny Stenback (:jst)]

This bug has been marked "future" because the original netscape engineer
workingon this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work in
some way -- please attach your concern to the bug for reconsideration.

Comment 4

[Johnny Stenback (:jst)]

*** Bug 65002 has been marked as a duplicate of this bug. ***

Comment 5

[Johnny Stenback (:jst)]

Getting this fixed for the next realease would be awesome, I'll look into it...

Comment 6

[Brian 'netdragon' Bober]

Confrontational are we? :) I am about to make a testcase with mas form elements.

Comment 7

[Brian 'netdragon' Bober]

Attachment: New testcase

Comment 8

[Brian 'netdragon' Bober]

Notice on my new attachment what I said is bad, necessary and unecessary to 
cause the "bug". This attachment shows that it is just the first element that 
gets thrown in front of the last element in order. It should stay the first.

Comment 9

[Johnny Stenback (:jst)]

*** Bug 48181 has been marked as a duplicate of this bug. ***

Comment 10

[Johnny Stenback (:jst)]

I must appologize here, I spoke too soon about pulling this back from the Future
milestone. I had a look at why this happens and how this could be fixed but
getting this right in mozilla will require some major surgery in the content
model and content sink code and I don't have time to do that for the next
release, unfortunately. Pushing this "Back to the Future".

Comment 11

[Jonathan S Abrams]

Updating keyword to 4xp, since bug 65002, which is a duplicate of this, had that
keyword.

Comment 12

[Eric Pollmann]

*** Bug 68679 has been marked as a duplicate of this bug. ***

Comment 13

[Eric Pollmann]

As in the dup:

This is due to DemoteContainer being called, and only happens for badly-nested
forms.  It should be fixed anyway!  :)

Comment 14

[Johnny Stenback (:jst)]

*** Bug 105398 has been marked as a duplicate of this bug. ***

Comment 15

[David Menestrina]

Attachment: Testcase exhibiting bug with unterminated <P>

Comment 16

[David Menestrina]

It seems that even some valid HTML can cause this bug, at least in build
2001082808.

If you have a <P> tag in a form without a matching </P>, then the element order 
will be messed up. My testcase shows this.

(HTML doesn't require a </P>, does it?)

Comment 17

[Phil Schwartau]

*** Bug 121726 has been marked as a duplicate of this bug. ***

Comment 18

[Phil Schwartau]

Here is a testcase from the duplicate bug 121726:

  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=66392

Comment 19

[Denis Antrushin]

All three testcases WORKSFORME on Jan 31, 2002 build

And please note that 121726 is not a dup - it's completely different
problem!

Comment 20

[Denis Antrushin]

Looks like it has been fixed on Nov 28 2001 as bug 109854, so this one 
can be closed

Comment 21

[Fabian Guisset]

Thanks for testing :) Marking FIXED by bug 109854.

Comment 22

[Prashant Desale]

verified on 02-06-10 with Linux.