Move a working condition (e.g. if field y has value x then show field z) inside of a fieldset (i.e. move both field y and z inside a fieldset) and it stops working.

CommentFileSizeAuthor
#2 1630606-2-conditions_in_fieldsets.patch2.04 KBfenstrat
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Scott M. Sanders’s picture

Scott M. Sanders CreditAttribution: Scott M. Sanders commented
Issue tags: +fieldset

I noticed this too. Workaround: don't put in a fieldset.

fenstrat’s picture

fenstrat
he/him
Primary language English
Location Australia
CreditAttribution: fenstrat commented
Status: Active » Needs review
FileSize
1630606-2-conditions_in_fieldsets.patch2.04 KB

Attached patch fixes this issue.

  1. Corrects the target_id to use '--' separator for each parent element (as theme_webform_element() does).
  2. Correctly resets radio button values. Setting radio.val('') results in it loosing it's value property altogether which stops the radio from submitting any value, whereas what is needed is to uncheck all values which is done with radio.val([]).
    I'd like quicksketch's input here, isn't nuking a components value when it's hidden a bit drastic? It'll wipe out any entered value, or default value. Couldn't the .val('') be removed alltogether?
quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

Thanks fenstrat!

I'd like quicksketch's input here, isn't nuking a components value when it's hidden a bit drastic? It'll wipe out any entered value, or default value. Couldn't the .val('') be removed alltogether?

It may be overdone, I agree. I believe I added the JS code to remove it when hidden to prevent client-side validation errors on fields. For example if you had an e-mail component in the form and entered some jibberish into it, then you hide the component by selecting a radio button (or whatever) on the same page. It's now impossible to move forward in the form because Chrome and Firefox are client-side validating the e-mail field saying "this isn't a valid e-mail", but because the field is hidden, you can't see the error. The form is just mysteriously broken.

Rather than removing the value, it would be better to implement an event listener for "invalid" on all form elements, so that if an HTML5 clientside validation is triggered, we can check if the element is even shown first. If it's not shown, suppress the default behavior (which shows the warning an stopping submission).

fenstrat’s picture

fenstrat
he/him
Primary language English
Location Australia
CreditAttribution: fenstrat commented

Cheers quicksketch.

Thanks for explaining the usecase, I'd not thought about client side html5 validation. Just tested in FF and Chrome with the invalid hidden email, it does exactly what you said. Broken form with no way to tell why!

Agree that listening for the invalid event and removing value if hidden is the way to go. Just had a quick look and I can't find any reference to the triggering of an invalid event for client side html 5 validation? Should probably be in a follow up issue though.

For now can we go with #2 as it fixes conditions in fieldsets and radios which are hidden.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Needs review » Fixed

I've committed the first part of #2, but omitted the second part as that's been fixed separately in #1677468: Non-text conditional component values deleted when hidden. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Code Trax’s picture

Code Trax CreditAttribution: Code Trax commented

Just an fyi, sub-fieldsets not hiding, based on the above patch I changed it to the following which corrects the issue:

$target_id = 'webform-component-' . str_replace('_', '-', implode('-', $target_parents));

Using Webform 7.x-4.0-alpha10(with 7.22)