Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#9386 closed bug (patcheswelcome)

Creating button set causes error if other type of input with same name found

Reported by: LordHamwich Owned by: LordHamwich
Priority: minor Milestone: none
Component: ui.widget Version: 1.9.2
Keywords: Cc:
Blocked by: Blocking:


Versions: jQuery 1.9.1, jQuery UI 1.9.2, jQuery Migrate 1.2.0

Affected: FF, Chrome, IE

Error message: cannot call methods on button prior to initialization; attempted to call method 'widget'

Description: Creating a button set from radio buttons inside a div, using div as a selector ($("#div").buttonset();) causes errors and graphical glitching in the button set if - for any reason - another input with a different type (in my test case hidden) sharing the same name as aforementioned radio buttons is found on the same form.


Change History (6)

comment:1 Changed 10 years ago by tj.vantoll

Owner: set to LordHamwich
Status: newpending

Hi LordHamwich,

Thanks for taking the time to contribute to the jQuery UI project.

This happens because the widget looks for radio buttons within the form and not within the buttonset:

Why would you need multiple inputs with the same name within a form? Both values submit, but this seems like a very strange thing to be doing, and it would add a decent amount of complexity to handle for this.

comment:2 Changed 10 years ago by LordHamwich

Status: pendingnew

Poor but known quick and easy hotfix for forcing empty value through post if no radio button is checked. Of course I got around that, but still thought that behaviour was strange.

Looking at that code, it just searches by name, right? So even a SPAN with a same name is causing the same errors and glitching.

Why would it even search inputs from outside of the selector element? API documentation states only that "Buttonset is used by selecting a container element (which contains the radio buttons) and calling .buttonset() ... It works by selecting all descendants and applying .button() to them".

comment:3 Changed 10 years ago by tj.vantoll

Resolution: patcheswelcome
Status: newclosed

Spans are not submittable elements and placing a name attribute on them is invalid HTML.

I'm going to close this as patcheswelcome. While technically you can have different fields in a form with the same name, I cannot think of a reason you would do this. If someone would like to change our implementation, we could look at a pull request.

If someone else on the team feels differently feel free to open this again.

comment:4 Changed 9 years ago by Scott González

#9570 is a duplicate of this ticket.

comment:5 Changed 9 years ago by ardoramor

As bug #9570 states, it is an issue with the way jQuery UI does radioGroup selection. That is, there is an error is the code. Function radioGroup's purpose is to select radio inputs (as the name implies), belonging to the same name group. However, it selects all inputs of the same name ( Also, it does not correctly replicate behavior of HTML standards as plain HTML would handle radio group and a text input of the same name (

As for the use case of applying the same name to various types of inputs, it is irrelevant. I believe that what made jQuery and jQueryUI so great is the tool set, a super set, they provided and not the ideology of how one thing should or should not be used. But not to sound like a jerk, my use of radio and input combination is as follows. I have created a metrics report tool. One of the dynamic parameters/filters that can be specified is the date range. The range consist of radio group containing today, last 7 days, month to date, year to date, previous month, and a custom date text input. When the user selects one of the radios, custom input gets disabled, when custom input is enabled, radios get deselected. This results in serialization to only one name instance.

comment:6 Changed 9 years ago by Scott González

Sounds pretty bad. You should make custom a radio and when it's selected, the text field is enabled.

Note: See TracTickets for help on using tickets.