If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

form.elements[] ordered differently than 4.x

VERIFIED FIXED in Future

Status

()

Core
DOM: Core & HTML
P3
normal
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: steve, Assigned: jst)

Tracking

({dom0})

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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?
(Reporter)

Comment 1

17 years ago
Created attachment 13360 [details]
Demonstrates strange ordering of elements[]

Comment 2

17 years ago
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 3

17 years ago
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.
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Target Milestone: --- → Future
(Assignee)

Comment 4

17 years ago
*** Bug 65002 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

17 years ago
Getting this fixed for the next realease would be awesome, I'll look into it...
Target Milestone: Future → mozilla0.9
Confrontational are we? :) I am about to make a testcase with mas form elements.
Created attachment 22343 [details]
New testcase
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.
(Assignee)

Comment 9

17 years ago
*** Bug 48181 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

17 years ago
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".
Target Milestone: mozilla0.9 → Future

Comment 11

17 years ago
Updating keyword to 4xp, since bug 65002, which is a duplicate of this, had that
keyword.
Keywords: 4xp
Keywords: dom0

Comment 12

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

Comment 13

17 years ago
As in the dup:

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

Comment 14

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

Comment 15

16 years ago
Created attachment 54811 [details]
Testcase exhibiting bug with unterminated <P>

Comment 16

16 years ago
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

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

Comment 18

16 years ago
Here is a testcase from the duplicate bug 121726:

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

Comment 19

16 years ago
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

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

Comment 21

16 years ago
Thanks for testing :) Marking FIXED by bug 109854.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 22

16 years ago
verified on 02-06-10 with Linux.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.