When using Firefox (version 2.x and 3.x on Mac, Win, Ubuntu) to edit the node form, if you reload the page (ctrl-r or View->Reload), radio button values are incremented down the list of buttons. For example, if you edit a node that has input formats of Filtered HTML, PHP Code (selected), and Full HTML, reloading the page will put the selected value of this set of radio buttons at Full HTML, the on second reload the value will be Filtered HTML, then on third reload the value will PHP Code. Same goes for any radio button group on the node edit page.

I'm only guessing that this behavior has to do with javascript since the HTML source shows the correctly selected radio buttons -- the incrementing behavior is only observable in the rendered page.

This behavior does not happen on IE or Safari. I've only tested this on core node options, not on CCK radio buttons, radio button groups added by contrib modules, or radio buttons added via form_alter(). I haven't been able to replicate this behavior on any other forms that use radio buttons, only the node edit form. I've only tested in in Drupal 6.6 and 5.12, and it doesn't happen in 5.12.

While most users are unlikely to reload the node edit form, if they do and then save their edits, radio buttons in collapsed field groups will have different values than intended, specifically, the next option in the list of radio buttons.

Comments

mr.baileys’s picture

mr.baileys
Primary language Dutch
Location 🇧🇪 (Ghent)
commented
Version: 6.6 » 7.x-dev
Issue tags: +Usability

Marked #375161: "comment settings" radio button changes when reloading the "edit" page as a duplicate of this one, since this one is the oldest. Copying my comment (partially) from that issue to this one:

I can reproduce this behavior on D7 (tested it with a book node). Tagged usability because of This often causes comments to be accidentally disabled for nodes where they should be left enabled.

Some observations:
1) bug occurs using Firefox 3.0.6, but does not occur on Chrome 1.0.154.48, IE7 and Opera 9.52 (all on windows)
2) bug only occurs on the node/x/edit page (where the comment section is added via hook_form_alter), not on admin/build/node-type/<type>
3) bug only occurs on a refresh. If you reload the page by pressing enter in the address bar, nothing strange happens
4) inspecting the GET on refresh and the normal get with Firebug show one difference: when refreshing, an extra header is sent with the get request: Cache-control: max-age=0
5) when the bug does happen, it advances one option per request (Disabled > Read Only > Read/Write), and restarts at Disabled on the request after "Read/Write".

@markj: looks like you are right when you suspect javascript. Disabling javascript in Firefox also makes this bug go away.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Issue tags: +JavaScript, +Firefox
mr.baileys’s picture

mr.baileys
Primary language Dutch
Location 🇧🇪 (Ghent)
commented

This seems to be a detailed description of the issue: http://www.ryancramer.com/journal/entries/radio_buttons_firefox/
And here's a bug report filed with Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=394782

Not sure how to proceed from here. It's a bug in third-party software, so I assume we don't want to make anything but minor changes on our end.

savioret’s picture

savioret commented

It happens in 6.x too

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Closed (won't fix)

There is nothing we can or should do. This is a bug in Firefox only.

savioret’s picture

savioret commented

Maybe modifying the radios by a select in hook_form_alter could be a temporary workaround ?