Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#8761 closed bug (fixed)

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

Reported by: reubenhelms Owned by:
Priority: minor Milestone: 1.11.0
Component: ui.button Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:

Description

My jsFiddle example is here http://jsfiddle.net/reubenhelms/ZtZu8/

This shows a radio set in a div that is formatted by buttonset() on a div. It also shows a hidden field that shares the same name as the radio set, but is outside the div targeted by the radio set.

Hidden fields often accompany a radio or checkbox field to send a value to the server, to denote the field exists, but nothing was selected.

When selecting an option in the radio set, a console error is generated "Uncaught Error: cannot call methods on button prior to initialization; attempted to call method 'widget'.

This error occurs because radioGroup() picks up all elements in a form that share the same name as the selected radio button, and then assumes that all items have associated buttons.

Restricting elements to the same type as the selected radio button, or restricting elements to the div of the original buttonset target would prevent this error, and allow the usage of hidden fields to denote an unselected buttonset.

Change History (13)

comment:1 Changed 4 years ago by scottgonzalez

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:2 Changed 4 years ago by reubenhelms

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?

comment:3 Changed 4 years ago by scottgonzalez

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.

comment:4 Changed 4 years ago by kristoffer

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.

comment:5 Changed 3 years ago by phazeii

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?

comment:6 Changed 3 years ago by phazeii

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

Last edited 3 years ago by phazeii (previous) (diff)

comment:7 Changed 3 years ago by tj.vantoll

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.

comment:8 Changed 3 years ago by tj.vantoll

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;
		});
	}
});

comment:9 Changed 3 years ago by scottgonzalez

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.

comment:10 Changed 3 years ago by tj.vantoll

  • Milestone changed from 1.10.0 to none
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Summary changed from click of a button in a buttonset console errors on elements not a part of the button set to Button: console errors on elements not a part of the button set

comment:11 Changed 3 years ago by scottgonzalez

  • Status changed from reopened to open
  • Summary changed from Button: console errors on elements not a part of the button set to Button: Non-button elements with the same name as a radio cause an exception

Ok, let's just add that check.

comment:12 Changed 3 years ago by TJ VanToll

  • Resolution set to fixed
  • Status changed from open to closed

Button: Ignore non-radio elements with the same name

Fixes #8761 Closes gh-1185

Changeset: ccb13240dd8b5cfac0199a30dcec4a71cbe1b252

comment:13 Changed 3 years ago by tj.vantoll

  • Milestone changed from none to 1.11.0
Note: See TracTickets for help on using tickets.