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:126.96.36.199) Gecko/20070309 Firefox/188.8.131.52
Also reproducible on: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:184.108.40.206) Gecko/20070312 Firefox/220.127.116.11
Created attachment 261887 [details] 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.
Created attachment 261888 [details] testcase Grr, this one should work online.
Created attachment 261891 [details] ok, this one should really work online
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!).
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.
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.
Sorry, I just found a bug that really is the same.