The attached sample form has two basic 'Select' fields, and saving a submission as a draft is enabled.
The fields have conditional logic to enforce one answer only: if 'Select first' is filled, 'Select second' is disabled, and vice-versa.

To reproduce:

- Choose 'a' in First select. (Second select will be immediately disabled)
- Click save. (Form will reload, partially - and correctly - filled)
- Change First select back to '- None -'. (Select second will become available again.)
- Change Second select to z. (First select will be disabled. All normal so far.)
- Click save.

Expected:

On page reload, form should be as it was before clicking save: First Select should is empty and disabled, Select second = z

Observed:

On page reload, First select = 'a' (the value we deleted), Select second = z and now, due to rules, user cannot change either value.

Note:

  • This can be done the other way around (start by setting Second select).
  • It happens whether AJAX is on or off.
  • it *only* happens with '#states' set - with no conditional logic, as you'd expect you can set and unset fields and save drafts without issue.

Webform 5.0.0-rc18
Drupal 8.5.6
All browsers (tested Safari, Chrome, Firefox)

CommentFileSizeAuthor
#11 2995154-11.patch2.8 KBjrockowitz
#9 2995154-8.patch8.61 KBjrockowitz
#9 Screen Shot 2018-08-28 at 5.53.40 AM.png61.47 KBjrockowitz
#5 Edit textfield element.png69.71 KBjrockowitz
#5 2995154-5.patch948 bytesjrockowitz
webform.webform.select_issue_demo.yml3.82 KBwturrell

Comments

wturrell created an issue. See original summary.

wturrell’s picture

wturrell commented

I did also try it with checkboxes (checkbox foo disabled if checkbox bar is checked) - all works correctly.

jrockowitz’s picture

jrockowitz commented

Something strange is happening because disabled elements should not be posted to the server.

Disabled elements in a form will not be submitted.

https://www.w3schools.com/tags/att_input_disabled.asp

Attached is webform that includes basic conditional logic to disable a text field and a simple text field that is disabled. Both elements are posting values to the server.

jrockowitz’s picture

jrockowitz commented

So Drupal core Form API's default behavior is to set the form state value for any element with a #value.

@see \Drupal\Core\Form\FormBuilder::handleInputElement

I am not sure if there is anything that we can do.

Clearing a disabled element's value does not seem like the right approach. Technically, 'disabled' means the user's entered value is not posted to the server and it makes sense that Form API would use the element #default_value.

Maybe removing disabled/enabled states makes the most sense.

jrockowitz’s picture

jrockowitz commented
Status: Active » Needs review
StatusFileSize
new 2995154-5.patch948 bytes
new Edit textfield element.png69.71 KB

The attached patch removes support for the enabled/disabled states and displays the below message for webform elements that are using these states.

We could try to dynamically restore these states if they are being used.

wturrell’s picture

wturrell commented

OK understood (I think). I suspect quite a few users might find that error confusing on it's own. I realise why it appears where it does, as the state no longer exists, but…

Just wondering how many other people might already be using that setting in production and will need to redesign forms (which admittedly may not have been working properly anyway). Another odd, possible, use-case: disabling the submit button until a confirmation checkbox is ticked?

I have several workarounds for my situation:

- redesigning form to merge the items from both (or more) select fields into a single dropdown (given only one is required)
- preserving existing layout, but adding a markup element with an error message (wrapped in the standard Drupal messages CSS classes) with its own conditional logic - so it's only shown when an invalid combination of inputs are selected, before user submits form
- using HOOK_webform_submission_form_alter to add a custom validation function

jrockowitz’s picture

jrockowitz commented

Maybe we just need to document that "Disabled elements do not post data back to the server and the element's server-side default or current value will be preserved and saved to the database."

wturrell’s picture

wturrell commented

Yes, I think that would work.

jrockowitz’s picture

jrockowitz commented
StatusFileSize
new Screen Shot 2018-08-28 at 5.53.40 AM.png61.47 KB
new 2995154-8.patch8.61 KB

The attached patch displays a warning message.

I also had to fix a weird but related somewhat issue where the disabled cardinality elements stopped triggering #states.

jrockowitz’s picture

jrockowitz commented
Related issues: +#2447189: #disabled not working if we use #states with disabled on element
jrockowitz’s picture

jrockowitz commented
StatusFileSize
new 2995154-11.patch2.8 KB

The attached patch just displays the message from #9. I think this is a reasonable solution. I agree that being able to conditionally disable elements and buttons is a useful feature.

wturrell’s picture

wturrell commented

Can confirm patch applies cleanly and works as expected.

  • jrockowitz committed 5369a88 on 8.x-5.x 
    Issue #2995154 by jrockowitz, wturrell: Old value retained after...
jrockowitz’s picture

jrockowitz commented
Status: Needs review » Fixed

@wturrell Thanks for the help.

Status: Fixed » Closed (fixed)

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