nsIDOMHTMLFormElement.elements ordering regression

RESOLVED INVALID

Status

()

Core
DOM: Core & HTML
RESOLVED INVALID
9 years ago
7 years ago

People

(Reporter: caggelop, Unassigned)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

Im using a javascript procedure to check/uncheck some radio buttons on a form.
User just enters numbers from 1 to 4 on an editbox and through Javascript, the corresponding radios getting checked/unchecked.
I wouldn't had had report this issue if all other browsers wouldnt work fine. But they do. I tryed IE, safari, chrome, opera and they do it pretty fine. 


Reproducible: Always

Steps to Reproduce:
1.Open the html attached with any other browser than firefox.
2.Put some numbers from 1-4 to the quickpick editbox at the bottom left corner
3.Keep your eye on radio buttons. They should check/uncheck depends of what number u put.

Actual Results:  
Wrong radios getting checked.
(Reporter)

Comment 1

9 years ago
Created attachment 385995 [details]
Htm that contains the quickpickproc() along with the bug

Comment 2

9 years ago
The script relies on the order of the input elements in the form "elements" property. The HTML contains this broken markup: http://tinyurl.com/n6wr4z

There are input elements in the table that aren't children of td elements, so they get moved before the table in the DOM.

In Firefox 2, the testcase works as expected. The input are still moved before the table, but the nsIDOMHTMLFormElement.elements preserves the order that is in the HTML.

In Firefox 3 and later, the nsIDOMHTMLFormElement.elements order matches the DOM order, so the input that gets moved before the table also appear before the other inputs in that array.
Component: General → DOM: Core & HTML
Keywords: regression, regressionwindow-wanted, testcase
OS: Windows Vista → All
Product: Firefox → Core
QA Contact: general → general
Hardware: x86 → All
Summary: Wrong javascript handling → nsIDOMHTMLFormElement.elements ordering regression
Version: unspecified → Trunk

Comment 3

9 years ago
Created attachment 386008 [details]
testcase
Regression range: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1185421620&maxdate=1185426359
Keywords: regressionwindow-wanted

Comment 5

9 years ago
Thanks for the regression range. This is a regression from bug 353415.

Apparently, a similar issue has been fixed in bug 390565. The parser doesn't move <input type="hidden"> elements, but here the input is of type=radio, and visually hidden using "display: none".

The reporter's testcase could be fixed in several ways:
 - moving the invisible <input type="radio"> inside the last <td> element (cleaner way).
 - using <input type="hidden"> instead of <input type=radio style="display:none">

I guess this is a WONTFIX.
Blocks: 353415
(Reporter)

Comment 6

9 years ago
(In reply to comment #5)
> Thanks for the regression range. This is a regression from bug 353415.
> 
> Apparently, a similar issue has been fixed in bug 390565. The parser doesn't
> move <input type="hidden"> elements, but here the input is of type=radio, and
> visually hidden using "display: none".
> 
> The reporter's testcase could be fixed in several ways:
>  - moving the invisible <input type="radio"> inside the last <td> element
> (cleaner way).
>  - using <input type="hidden"> instead of <input type=radio
> style="display:none">
> 
> I guess this is a WONTFIX.

Thanks Sylvain for the suggestion and sorry for the broken markup.

Comment 7

9 years ago
no need to be sorry ;-), broken markup is part of the Web and we have to deal with it the best way.
Invalid; the collection must be in tree order, not in markup order. <http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#collections>
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.