populated OPTION field can't be made empty

Bug #591401 reported by Xavier Brochard
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Woda
Fix Committed
Medium
Unassigned

Bug Description

Imported from the mailing list. Original reporter is Richard Wohlschlegel

A previously populated OPTION field, using checkboxes or multiple select options (typePar CHECKBOX or MULTIPLE), can't be made empty.

When you try to change the setting of this field from any setting to none of the options selected the last stored value will persist, i.e. you can have all checkboxes selected and deselect all then all checkboxes remain selected.

Woda and Perl all versions.

Related branches

Revision history for this message
Xavier Brochard (xavier) wrote :

Trying to get this bug solved, I'm more and more thinking that it is due to normal handling of html forms.
See http://www.w3.org/TR/html401/interact/forms.html#h-17.13
"A successful control is "valid" for submission. Every successful control has its control name paired with its current value as part of the submitted form data set.
...
When no options are selected, the control is not successful and neither the name nor any values are submitted to the server when the form is submitted."

In other words, when no options are selected in a multiple select form or no checkboxes is checked, the browser send nothing.

If one want to verify, simply point your form to http://www.htmlcodetutorial.com/cgi-bin/mycgi.pl

One can also install the well known cgi-lib.pl and use it to print the form's datas submitted: nothing is submitted for unchecked checkboxes or empty select field.

Changed in woda:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Xavier Brochard (xavier) wrote :

WORKAROUNDS:

1. A work around is to add an empty value and to use it to blank the field: ask users to uncheck all the checkbox but to check the empty one: it will blank the field.

Something like this
note that there is a TAB before parenthesis at first options line:

$x='OPTIONS'; # ------------------------------
$WBF{$x,srt}=$i--;
$WBF{$x} = '1;';
$WBF{$x,'type'} = 'OPTION';
$WBF{$x,'options'} = ' (check this for none and uncheck the others)
potentially
maybe
probably';
$WBF{$x,'typePar'} = 'CHECKBOX';
$WBF{$x,'d'} = '';
$WBF{$x,'p'} = 'Any of these or none';

The field will not really be empty, but it can help.

2. A better but more complicated woraround would be a script launched with the $WBB{'AfterRecordModify'} setting.

Other suggested workarounds can't work because they only strip the content, thus the browser still submit nothing.
These were:
- A change WBF,# $WBF{$x,'change'} = ''; with a test against the "none" value to erase the field.
- Add a special OPTION field with a RADIO button to help erase the options, and use Javascript to make previous field empty

Revision history for this message
Xavier Brochard (xavier) wrote :

By commented out these lines in cgiChanged, everything works well.

        # preserve values we were not allowed to edit into oldrec

        foreach $x ( keys(%rec) ) {
     $oldRec{$x} = $rec{$x} unless defined $CGI{$x}; # was not on form

            next if $WBF{ $x, 'modifies' } eq ''; # everyone modifies
            next if $Group =~ m/admin|$WBF{$x,'modifies'}/; # I modify
            $oldRec{$x} = $rec{$x}; # I don't modify
        }

Revision history for this message
Malcolm Fitzgerald (malcolm-notyourhomework) wrote : Re: [Bug 591401] Re: populated OPTION field can't be made empty
Download full text (3.9 KiB)

This is quite a tricky problem. It is an issue that is caused by the way in which the HTML form input elements of type checkbox are handled. Empty checkbox items do not return a value, only checkbox items with actual values are returned to %CGI.

For WODA this raises a serious issue - if no value is returned to %CGI how can it know which fields are on the form? It cannot. WODA can only rely on the information in %ENV and %CGI.

Here is a very simple web page which illustrates the problem. You can try this out for yourself.

<html><body><form ><input name="boo" ><input name="hoo" type="checkbox" value="a">a<input name="hoo" type="checkbox" value="b">b</form></body></html>

Load this page in your browser. Put the cursor into the first field and press the enter button. The values of the form will appear in the URL.

If the field "boo" is empty it returns an empty value but the field "hoo" will only have checked values returned.

An option, already discussed, is to have a default value with a clear label, such as "None of these" in the checkbox options. That may work for in-house solutions but it is a fairly weak option for general use as it requires the user to know that they must clear all the other values and check the "none" box.

A better work-around is to have the field appear on the form as another TYPE, like this <input name="hoo" type="input" value="">. This forces the field "hoo" to be defined in %CGI. This may offer a sensible way forward. For checkboxes it is quite common to offer a short list of common choices and then to have standard text input field labelled "Other" which allows the user to add their own values. The input type for this extra element could be set to "hidden" if you do not want users to have the option to include other values. If we were able to design the WODA form so that this extra element was included automatically it would resolve the issue.

We must remember that this issue only occurs with checkboxes. I suggest that by default we always add an input field with an empty value when a CHECKBOX list is displayed. It would often be useful if it were not hidden but for backward compatibility we should not display this. It would have to be added by default as a hidden input element.

Having an option to specify whether this extra element was hidden or displayed would be best. I think that we could use WBF->typePar for this too. If we decided to do this we could say "CHECKBOX OTHER" where the word OTHER would be the flag which determines that the input field should be visible.

Do you have other thoughts or comments on this suggestion?

Malcolm

On 09/06/2010, at 5:17 AM, Xavier Brochard wrote:

> By commented out these lines in cgiChanged, everything works well.
>
> # preserve values we were not allowed to edit into oldrec
>
> foreach $x ( keys(%rec) ) {
> $oldRec{$x} = $rec{$x} unless defined $CGI{$x}; # was not on form
>
> next if $WBF{ $x, 'modifies' } eq ''; # everyone modifies
> next if $Group =~ m/admin|$WBF{$x,'modifies'}/; # I modify
> $oldRec{$x} = $rec{$x}; ...

Read more...

Revision history for this message
Xavier Brochard (xavier) wrote :

Comment from Claudio Rivetti (imported from the mailing list)
in woda.pl, sub wbFormFieldItems

for typePar CHECKBOX, MULTIPLE
add a hidden input field with the same name of the field like this:

$Form{$field,input} .= &formatColumns($cols,@x) . "<INPUT TYPE=HIDDEN
NAME=\"$field\" value=\"\">";

upon form submission an empty value will be passed even if chackboxes
are not selected.

If you do not want to modify woda.pl, add the hidden input field to
the $WBF{$x,'help'} variable of the field. In this case it works if
help is on.

Revision history for this message
Xavier Brochard (xavier) wrote :

For the record:
One could think that we need a simple test about browser sending value or not. Then, if not, woda blank the field.
But it is not possible.
Because user's defined forms, may not contains all the fields.

Xavier Brochard (xavier)
Changed in woda:
status: Confirmed → Fix Committed
Revision history for this message
Xavier Brochard (xavier) wrote :

fix in rev. 183, 4.620 branch. Thanks to Claudio Rivetti.

Xavier Brochard (xavier)
Changed in woda:
milestone: none → merge-with-pro
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.