Default value ignored for radios in tables due to faulty JS

Checked attribute? What does your $form look like? Are you using #default_value? See http://api.drupal.org/api/file/developer/topics/forms_api_reference.html...

Yeah, I noticed this as well, while doing last minute testing on Drupal 6 RC2, but was completely puzzled about it. If it has checked="checked" on it like I also noticed in the code, it should be selected. So I don't think this is a server side problem.

http://drupal.org/node/208878 appears to be related, if not the same issue. In that issue it is related to the browser being used (IE6, IE7, and Opera 9.25 are working, others are not).

Marked these as duplicates:
http://drupal.org/node/205080
http://drupal.org/node/204948
http://drupal.org/node/208878

After a quick look around core, I'm not seeing any radio's selected on:
admin/settings/filters
admin/user/user
admin/build/block/add
admin/user/user
admin/build/themes

Radios are OK on a number of other pages including:
admin/settings/performance
admin/content/types/add.

Works on IE7:
admin/settings/filters
admin/build/themes

admin/user/user (http://drupal.org/node/204948) may not be the same issue. It behaves this way in D5 as well, so it may be by design.

There was a patch for this same behavior for the caching mode selection in http://drupal.org/node/198332.

Maybe the issue here is the difference between 'radio' and 'radios' fapi type?

perhaps this is a problem for radios being rendered out in a table?

on some page's it's fine, such as: admin/settings/clean-urls

On others like: admin/build/themes It's broken. As above - if you look at the page source you see that the default is indeed correctly marked.

I just tried disabling JS and everything returns to normal - it's probably another problem with tableheader.js or some such.

Confirmed - after disabling javascript (Firefox 2), and ctrl-F5, the radios appear.

Confirmed - after deleting tableheader.js, the default values of radios are visible.

This looks to me like a bug with jQuery. Cloning the table and moving it within the DOM is causing it. Previous iterations of the tableheader.js patch only cloned 'thead' but I thought I was being clever doing the whole table since it would inherit more of the original's styles and whatnot. –I'll look into this.

And this isn't critical.

Hmmm - I think it is critical if the admin interface is partly unusable.

Also - there seems to be another bug, perhaps with the ID applied to the cloned header. At least on admin/build/themes in FF DOM inspector, the id of the cloned tables shows as "undefined-header". Apparently this code needs to check for "undefined", since

If the element does not have an attribute with such a name, undefined is returned.

http://docs.jquery.com/Attributes

    // Sets an id for cloned table header.
    var headerID = headerClone.attr('id');
    if (headerID != '') {
      headerClone.attr('id', headerID + '-header');
    }

Attached patch fixes that problem, but not the radio selection.

This patch does away with cloning the whole table. Only thead is cloned.

The id for the clone was never needed. That was part of a followup patch to resolve a conflict with draggable table rows so it's been removed since it would never create duplicate id's for the table.

Tested in Opera 9.25, Safari 2/3, FF 2 and IE7. All issues seems to be fixed and this includes Safari 2 crashing.

And this extra line added helps Safari keep the header cells aligned when the contents of a body cell pushes the width of all the columns. You can see an example of this in the theme admin page where the screen shots push the widths.

e.resizeWidths = true;

Previously wasn't an issue but that addition doesn't harm anything else.

I tested #14 on my FF2/Linux, both Garland and custom theme, including forms-in-tables and drag-and-drop. All fine, radios defaults now working, and nothing broken. Should be RTBC, but not setting as such yet, because I can't test with other browsers than FF.

Tested on Windows Vista with:

Firefox 3 (Minefield nightly)
Safari 3
Opera 9.2.4
IE7

Patch works as expected - no issues with radios, table headers or drag & drop.

Thanks, committed.

Still a problem in Drupal 7, this needs to be forward-ported.

Is this still a problem? I can't reproduce it on the D7 equivalent of any of the example pages cited above.

The tableheader.js code has changed quite a bit in D7, so I suspect this bug no longer exists.

Just a comment in case anyone else finds this useful. I saw the same symptoms on a form I had built in a D6 module but the solution was different: I needed to remember to include

$form['#tree'] = TRUE;

And that fixed everything.

If reopened please provide sample code.

Just reproduced this in my contrib Devel images provider, in the branch 7.x-1.x plugins.

• Install devel
• Get the branch 7.x-1.x plugins of devel image provider from git and install it
• Access admin/config/development/devel_generate_image_provider
• Remove remove $form['#tree'] = TRUE; from devel_image_provider_providers_form function
• Access again admin/config/development/devel_generate_image_provider