Skip to content

horizontal Grouped Radio Buttons don't get checked #2553

ninichki opened this Issue Sep 28, 2011 · 9 comments

7 participants


The new nightliy build Jquermobile don't set the horizontal grouped radio inputs to checked.

thanks for the nice work.


Can you post a jsbin or jsfiddle illustrating the issue you're seeing? These seem to toggle:

ninichki commented Oct 4, 2011

Year they toggle, but shouldn't the underlying input tag get a checked html - attribute?


Swaagie commented Jan 12, 2012

confirmed, running into the same issue, no need for jsfiddle, shows similar behavior...

Original input never gets checked="checked"

@Wilto Wilto was assigned Jan 12, 2012

Is this on every browser on just a specific one? Looking into this now.

@Wilto Wilto added a commit that closed this issue Jan 12, 2012
@Wilto Wilto Fixes #2553 — Addresses issue where underlying checkboxes/radio butto…
…ns were not being updated when enhanced buttons were clicked.
@Wilto Wilto closed this in 8da75eb Jan 12, 2012
@karol-f karol-f pushed a commit to karol-f/jquery-mobile that referenced this issue Jan 13, 2012
@Wilto Wilto Fixes #2553 — Addresses issue where underlying checkboxes/radio butto…
…ns were not being updated when enhanced buttons were clicked.

Hey all

I'm not positive, but I think this was configured better before this change - not sure it was actually a bug. While it's confusing that the checked attribute wasn't updating, I think that's actually expected behavior for properties like "checked", in which the attribute delivers an initial property value of the element, but after that, we'd update the property rather than the attribute. With that original system in place, to check the value, you could use prop() instead of attr()

We switched from attr() to prop() when jQuery core added the method, since in theory, prop should be used for manipulating properties like this after load. Now that it's using attr() again, I don't think the input's actual checked property is being updated anymore, and the new issue #3670 suggests as much. Setting the attribute may be sufficient for form submission
(did we test that?), but I'm not sure it digs in to set the property itself.

By using attr() to change the value, jQuery's ":checked" selector doesn't seem to find the property, but "[checked]" does, since we're updating the attribute.

I noticed we still have the prop()-based version in the code, commented out beneath it.

@wilto - I think this was a pull you might have approved... Maybe you could chime in on why we needed to change this back to attr()? I wonder if the following is the change we might need to make:

input.prop( "checked", inputtype === "radio" && true || !input.prop( "checked" ) );

(before, in the commented-out code, the second call to prop there was using attr() instead, which may have been the real cause of the bug originally. maybe...)

Here's the commit that caused the regression. karol-f@f269788



This one works fine with latest, going to the docs pages referenced

Scrolling to the bottom and selecting the last radio button in the horizontal group and

$("[data-type=horizontal] [name=radio-view]").last().is(":checked")

Will get you true.


If this really closed ? With Chrome 19, Opera 12 and Firefox Nightly on I still have this problem... Look at the button, neither
List, Grid or Gallery's original input get checked.



Unless I've misunderstood your comment:

Alt text


You're right, $('input[name=radio-view]:checked') returns the selected item. What confuses me is that the DOM do not reflect this state (where is the checked attribute?). Also, and consequently, $('input[name=radio-view][checked]') do not return this item.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.