377815 - radio button group's selected index changes on page reload when adding other inputs dynamically via JS

Status: RESOLVED DUPLICATE of bug 311507

(Core :: DOM: Navigation, defect)

Description

[mdawaffe]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a4pre) Gecko/20070417 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a4pre) Gecko/20070417 Minefield/3.0a4pre

This is not a duplicated of bug 46845.

After reloading a page in which INPUT elements have been dynamically added to the page above a group of radio buttons, the selected index of those radio buttons will shift depending on the number of dynamically added INPUT elements.

Reproducible: Always

Steps to Reproduce:
See attached test case.

OR

1. Create a page with one group of radio buttons, have the first radio button be selected by default (not necessary: included for clarity). 
2. Using .innerHTML, add one other INPUT element (text, hidden, button: doesn't matter) above the radio buttons during window.onload
3. Reload the page by clicking the reload button in Firefox's toolbar.
Actual Results:  
The selected index of the radio buttons increments by one on each page reload.

Expected Results:  
The radio button that was selected before reloading the page should stay selected after reloading the page.

If you dynamically add N > 1 INPUT element above the radio buttons, the selected index of the radio button will increment by N on each page reload.

Originally reported as bug in WordPress:
http://trac.wordpress.org/ticket/3895
(see http://trac.wordpress.org/ticket/3895#comment:26)

Example test case attached.

Also reproducible on:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Comment 1

[mdawaffe]

Attachment: HTML test case

Comment 2

[mdawaffe]

Also reproducible on:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11

Comment 3

[mdawaffe]

My first bug report.

The attached test case does not work if previewed here on this site because javascript is really sloppy.  It will work if you download source and try it out locally.

Comment 4

[Martijn Wargers (dead)]

Attachment: testcase

Thanks for the bug report, Mike. This is a testcase that should work online.
This indeed seems like a valid bug, but first I'm trying to find out if this isn't a duplicate of some other bug.

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

Grr, this one should work online.

Comment 6

[Martijn Wargers (dead)]

Attachment: ok, this one should really work online

Comment 7

[Martijn Wargers (dead)]

Ok, there is at least one bug that was filed earlier and is also about this issue, so I'm marking this a duplicate of that bug (but still thanks for filing the bug!).

Comment 8

[Martijn Wargers (dead)]

Argh, sorry, not a duplicate, the testcase in that bug reacts differently in current trunk build. But still, this bug is probably related to that bug.

Comment 9

[mdawaffe]

Thanks for cleaning up the testcase, Martijn.  Bug 372887 looks remarkably similar; I agree they must be related.

If you want to see the N > 1 case, I've got an attachment I'm about to upload that might work.  If it doesn't work, I'm giving up on the testcases.  Yours works perfectly on its own.

Comment 10

[mdawaffe]

Attachment: N > 1 testcase. Martijn's is much cleaner.

Comment 11

[Martijn Wargers (dead)]

Sorry, I just found a bug that really is the same.