This project is archived and is in readonly mode.

#1863 ✓resolved
ronin-18882 (at lighthouseapp)

check_box doesn't work with nested forms

Reported by ronin-18882 (at lighthouseapp) | February 3rd, 2009 @ 11:26 PM

When using check_box in a nested form, the value that gets passed to the controller is always the value of the check_box's hidden field. Even if the checkbox is selected, it will not pass the appropriate value.

Comments and changes to this ticket

  • ronin-18882 (at lighthouseapp)

    ronin-18882 (at lighthouseapp) February 3rd, 2009 @ 11:45 PM


    the parameters parse correctly when using :get but not :put

  • Eloy Duran

    Eloy Duran February 4th, 2009 @ 08:39 AM

    Could you please provide some details; code/log etc.

    Because in my example it works perfectly:

  • Eloy Duran

    Eloy Duran February 6th, 2009 @ 10:51 AM

    Could you indicate which version of Rails you are using? Because I want to make sure we don't confuse the addition of NestedAttributes to 2.3RC1 with this issue.

  • Bartosz Pietrzak

    Bartosz Pietrzak February 6th, 2009 @ 03:08 PM

    I have the same situation in Rails 2.3 RC1

    form.check_box :agree

    creates an input type="checkox" and hidden input with value 0, here are the http headers:

    -----------------------------21129738941962649666904118542 Content-Disposition: form-data; name="appl[agree]"

    1 -----------------------------21129738941962649666904118542 Content-Disposition: form-data; name="appl[agree]"


    first one is valid (from the checkbox) and the second isn't... and in params I do always get the value 0.

  • Eloy Duran

    Eloy Duran February 6th, 2009 @ 03:41 PM

    My question is actually if this has to do with NestedAttributes which was added in 2.3RC1 or that the author is talking about nested attributes in older versions of Rails.

  • ronin-18882 (at lighthouseapp)

    ronin-18882 (at lighthouseapp) February 6th, 2009 @ 04:39 PM

    Yes. This is in reference to 2.3RC1

    I believe I've gotten closer to solving the problem. This only occurs when posting a form with :multipart => true

    Therefore, I believe there is some inconsistency in the way that rack parses input parameters when reading data from a multipart form. The hash that is returned has the wrong values when it is returned from rack, even before it hit the parser in rails.

    Not sure if this should be reported with the rack guys or if it can be handled here.

  • Eloy Duran

    Eloy Duran February 6th, 2009 @ 04:48 PM

    • Assigned user set to “josh”
  • josh

    josh February 7th, 2009 @ 04:48 AM

    • Milestone cleared.
    • State changed from “new” to “open”
  • josh

    josh February 7th, 2009 @ 06:11 AM

    Just bundled Rack master with the its params parsing stuff. Can you please test against that. Then we can determine if its something that needs to be patched against Racks parser or our extensions to it.

    Also unit tests would be much appreciated too :)

  • René Rask

    René Rask February 10th, 2009 @ 06:25 PM

    I'm assuming this is related, but I'm not sure.

    If the checkbox isn't select I get the correct value from the hidden field. Otherwise I get both values as an array.

    This happens for both regular forms and nested forms.

    Selected checkbox returns these params: "available"=>["1", "0"] Not selected checkbox return these params: "available"=>"0"

    I'm using the current: rake rails:freeze:edge

    Using 2.2.2 gives me the correct params: "available"=>"1"

  • Repository

    Repository February 10th, 2009 @ 07:19 PM

    • State changed from “open” to “resolved”

    (from [f400209084fabb00e18c3325e1933f4543fce94c]) Move checkbox hidden field before the actual checkbox so the actual value doesn't get clobbered [#1863 state:resolved]

  • josh

    josh February 12th, 2009 @ 05:59 PM

    • State changed from “resolved” to “open”

    This issue is still huge. 2.3 blocker.

  • josh

    josh February 15th, 2009 @ 12:17 AM

    • State changed from “open” to “resolved”
  • Soph

    Soph April 16th, 2009 @ 04:16 PM

    I hope it is ok to add this to this ticket, but it looks like the best place for me.

    According to the Rails-API-rdoc:

    "To prevent this the helper generates a hidden field with the same name as the checkbox after the very check box. So, the client either sends only the hidden field (representing the check box is unchecked), or both fields. Since the HTML specification says key/value pairs have to be sent in the same order they appear in the form and Rails parameters extraction always gets the first occurrence of any given key, that works in ordinary forms."

    If i get everything right, with the changes in this ticket rails now uses the last occurrence of any given key, or otherwise putting the hidden box before the checkbox wouldn't work. I wonder if there are other places where this could raise problems? And maybe the rdocs should be changed. "first" -> "last". We run into this, when some of our tests failed after upgrading to 2.3.2. We used find_tag and checked for the first occurrence, since this is now the hidden tag, testing for "checked" and "disabled" failed.

  • csnk

    csnk May 18th, 2011 @ 08:21 AM

    • Importance changed from “” to “”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>

Referenced by