Values for checkboxes in $form_state do not match input

sub

I understand that this isn't likely to receive much attention due to being able to handle things via e.g. node_save() or another alternative method, but I've been struggling against this bug for hours because nowhere does it state that drupal_form_submit() shouldn't just work.

The documentation even includes an example for creating a user. If there were select fields involved, it would fail.

Is there any progress on this? I am working on some advanced forms, which do not work because of this bug. Re-implementing drupal_form_submit is not an option for me... Does this also happen in 7.23?

I am running into the same issue.
My use case is quite advanced so I hesitate trying to explain it here.
It has to do with views_ui and ajax (D7).

I reproduced this issue too.
We can reproduce it only when using drupal_form_submit() programmatically. In this case we have to use the input value instead of #return_value because we are setting new values via form_state. Like this:

$form_state['values']['my_checkbox'] = 0;
drupal_form_submit('my_form', $form_state);

See form_type_checkbox_value() and _form_builder_handle_input_element:2119.

I prepared a simple patch to fix it.

Updated the patch. We need to skip cases when checkbox is the entity field.

The latest patches do not apply anymore.

Updated the #8 patch, the patch on #10 applies cleanly. please review.

I created a MR with the same changes in the patch in comment #7.

[Please ignore this comment.]

The description of the return value needs to be changed too.

The data that will appear in $form_state['values'] for this element, or nothing to use the default.

form_type_checkbox_value() always return a value, even if that value is 0. It is not true it can return nothing. That comment cannot be changed to or 0 to use the default either. That would contrast with the comment inside
form_type_checkbox_value(), which contains the following sentence.

Returning NULL from a value callback means to use the default value, which is not what is wanted when an unchecked checkbox is submitted, so we use integer 0 as the value indicating an unchecked checkbox.

For a checkbox, 0 returned from form_type_checkbox_value() means the checkbox is unchecked.

Furthermore, this comment should be changed too, since the code is changed.

// Checked checkboxes are submitted with a value (possibly '0' or ''):
// http://www.w3.org/TR/html401/interact/forms.html#successful-controls.
// For checked checkboxes, browsers submit the string version of
// #return_value, but we return the original #return_value. For unchecked
// checkboxes, browsers submit nothing at all, but
// _form_builder_handle_input_element() detects this, and calls this
// function with $input=NULL. Returning NULL from a value callback means to
// use the default value, which is not what is wanted when an unchecked
// checkbox is submitted, so we use integer 0 as the value indicating an
// unchecked checkbox. Therefore, modules must not use integer 0 as a
// #return_value, as doing so results in the checkbox always being treated
// as unchecked. The string '0' is allowed for #return_value. The most
// common use-case for setting #return_value to either 0 or '0' is for the
// first option within a 0-indexed array of checkboxes, and for this,
// form_process_checkboxes() uses the string rather than the integer.

we return the original #return_value is not always true, as $input is returned for programmatically submitted forms.

I did not change the other phrase.
Given the context in which it is used (browsers submit the string version of #return_value, but we return the original #return_value), it is not necessary to say that also $input could be returned.