<textarea>s using Text Editor always fail HTML5 validation when "required" is added via #states

This is still an issue even though #1954968: Required CKEditor fields always fail HTML5 validation → was already merged a long time ago. That solution did not account for a change of states.

Also, this is minor at best, this is an extreme edge case that will at most affect 0.01%
Conditionally marking a field as required using #state makes no sense to me, because it means Form API (the server side) can't enforce it. What am I missing?

I think there are two assumptions being made here.

1. Assumption: It doesn't affect a lot of users. - I think it does, I have run into this on the past several large govt projects I have worked on. Each time we have to come up with less than ideal solutions.
2. Assumption: Conditionally marking it as required is nonsensical because the api can't enforce it. - This is not always true. Sometimes we go to the extent of writing constraints and validators to enforce it. Unfortunately it never gets that far because html5 validation prevents it from ever making it that far, but the editor has not idea because ckeeditor mangles the field id so it no longer is focusable.
3. Assumption: it is not a bug. - #states supports requiredness, so it is a bug that any field using ckeditor can not properly get passed html5 validation if it was set by #states.

2. #states supports it, so it is a bug that any field using ckeditor can not properly get passed html5 validation

I agree with swirt, I am facing this issue a lot with too many projects as well!

This is reported on Drupal 8, which is no longer supported. Does this problem exist on a supported version of Drupal? If so, update the version value. Thanks

Yes this is still an issue in the D9. Can not say for certain on D10

This is an issue on Drupal 10.1.

@Wim Leers, here is the 0.01%! :)

We have many fields conditionally marked as required by states and having that enforced by symfony constraints on API level.
There are custom fields with multiple subfields (columns) shipped by several contributed modules which might require such logic on any site. So I believe it is a real issue, just like others mentioned before me.

The patch didn't work for me, and for some reason even when it worked, for some paragraph fields, the reinitialization placed an additional editor after the first one, so I ended up having 2 complete editors rendered for a single field.

So I tried to come up with a simple and clean workaround this problem, which basically keeps the editor's source element up to date via a listening to the change event inside the editor model. So when submit happens, the source element contains the data from the editor.

Pasting the JS code here:

/**
   * Handle CKEditor change event to keep the source element up to date.
   *
   * @type {Drupal~behavior}
   */
  Drupal.behaviors.ckeditor5SourceElementUpdater = {
    attach: function (context, settings) {
      let $context = $(context);

      // Iterate through all CKEditors on the page.
      $(once('ckeditor5-states', $context.find('[data-ckeditor5-id]').filter(':input'))).each(function () {
        if (this.dataset.ckeditor5Id) {

          let editorId = this.dataset.ckeditor5Id;
          // Using setTimeout() in order to ensure all CKEditors are loaded.
          setTimeout(function() {
            const editor = Drupal.CKEditor5Instances.get(editorId);

            if (editor) {
              $(once('ckeditor5-states-binding', editor.sourceElement)).each(function() {
                editor.model.document.on('change', function () {
                  if (editor.getData() !== editor.sourceElement.textContent) {
                    editor.updateSourceElement();
                    $(editor.sourceElement).trigger('change', [true]);
                  }
                });
              });
            }
          });
        }
      });
    }
  };

Off-topic: I actually worked on something related a few weeks ago: 🐛 Regression from #3341682: #states + #required do not automatically work together, resulting in an unsubmittable AccountSettingsForm Fixed , but almost the opposite direction.

On-topic: let's start with writing a failing functional JS test that shows the problem, so that we can fix this and never regress again! 😊 Then the JS snippet in #13 should make that test pass. 👍

Pushed the test only to the MR which will fail.

Pushed the fix which made the test pass.

Issue summary appears incomplete. Please use the standard issue template.

I just updated the summary to use the template.

Left 2 comments on MR, one is nitpicky but believe return docs should be included.

pradhumanjain2311 → made their first commit to this issue’s fork.

Fix from related MR worked for me on Drupal core 10.2.2 and Conditional Fields 4.0.0-alpha5.

Needs review from community and we can include it in next release to fix this and related https://www.drupal.org/project/conditional_fields/issues/2988937 🐛 Dependency using body as target results in "An invalid form control with name='body[0][value]' is not focusable." with ckeditor enabled Needs review

Reading early comments I should of also tagged for steps to reproduce early on. It helps reviewers/committers to be able to quickly see how to reproduce the problem.

The whole point of pushing test before the fix was to prove the problem. Please see #16.
I really don't understand now what is the matter here.
Tests are there, they tell what is the exact problem, besides the multiple comments above.

Purpose of the issue summary is to be able to quickly get up to speed just fyi

Issue summary appears clear and all feedback on MR resolved.

few comments