Button: Non-button elements with the same name as a radio cause an exception

I've seen people add hidden fields to accompany checkboxes, but they usually have a different name and then there's som server side logic that detects the hidden field being submitted and knows that the checkbox should be handled even if it's not submitted. However, I've never seen someone use the same name before. I don't think this is something that the widget should handle as it's quite confusing to mix types while using the same name.

That's a little disappointing. My own example comes from CakePHP, except that I've modified it slightly to move the hidden field outside of the div.

How many frameworks that generate radio inputs with an accompanying input field in that manner would it take, before considering that it is a standard practice to use the same name?

I honestly can't give you an exact number, but I can tell you that button has been in stable jQuery UI releases for 2.5 years and this is the first time someone has reported this. Perhaps you can ask CakePHP why they use the same name or see if someone from their dev team is willing to make a strong argument in support of this on this ticket.

I would say that this way to validate a radio set worked very well with jQuery UI 1.8. With that said, I would consider this as a bug. Try to change the jQuery UI version from 1.9.1 to 1.8.24 in the jsFiddle posted in the bug report and you will see that the buttonset works as expected.

I believe Yii framework does it as well. I've seen it in quite a number of places myself. Just came across this bug and would be good to see it fixed.

It's more often seen with checkboxes ala:

<input type="hidden" name="mybox" value="0">
<input type="checkbox" name="mybox" value="1">

So the value is submitted if the box is unchecked.

Also seen as popular solution here : http://stackoverflow.com/questions/1809494/post-the-checkboxes-that-are-unchecked

And it does actually seem to work just fine with a hidden if it's with checkboxes:

http://jsfiddle.net/ZtZu8/40/

So should it not have the same functionality with radio's as well?

Sorry about the double submit, it said there was a captcha error the first time.

scott.gonzalez: Are you ok with moving

radioGroup

into a method on the prototype? I think this is an edge case, but right now if you're using a framework that does this you're screwed.

With

_radioGroup()

, this extension solves the problem:

$.widget( "ui.button", $.ui.button, {
	_radioGroup: function( radio ) {
		return this._super( radio ).filter(function() {
			return $( this ).parents( ".ui-buttonset" ).length > 0;
		});
	}
});

Well, I definitely don't want to document it as a supported method. Let's see what the performance hit is for including [type="radio"] in the selector.

It's trivial: http://jsperf.com/type-filtering-check

Ok, let's just add that check.

Button: Ignore non-radio elements with the same name

Fixes #8761

Closes gh-1185

Changeset: ccb13240dd8b5cfac0199a30dcec4a71cbe1b252