contentTranslationDependentOptions behavior doesn't check if found element array is empty

We could add a test but I'm not sure if we should. The issue is a missing conditional safeguard to avoid using an empty array as it is not empty. I'm not convinced we should add a new test to core, adding a few seconds to each test run, for this simple issue.

This is the original code:

      if (options && options.dependent_selectors) {
        Object.keys(options.dependent_selectors).forEach((field) => {
          $fields = $context.find(`input[name^="${field}"]`);

          const dependentColumns = options.dependent_selectors[field];

          $fields.on('change', fieldsChangeHandler($fields, dependentColumns));
          Drupal.behaviors.contentTranslationDependentOptions.check(
            $fields,
            dependentColumns,
          );

$fields is passed to Drupal.behaviors.contentTranslationDependentOptions.check but it is empty.

I've uploaded a video with the issue, showing the problem in Simplytestme and the fix applying the patch.
See https://www.drupal.org/files/issues/2023-12-20/20231220-Drupal-issue-341...

Of course, we can still add a test, but I would say we should test JS is not broken in the /admin/config/regional/content-language page. That would be a more general test. Not sure if this is the proper place, it could be better to use this issue to add it.

The test was trickier than expected. I needed to install the standard profile to get a failing test. Enabling content translation or the minimal profile was not enough. I guess the problem are the entities created.

This is the "Content language and translation" page (/admin/config/regional/content-language) with the standard profile:

And this enabling only the content translation module:

As expected test passes but the "Test-only" job fails, demonstrating the issue.

See https://git.drupalcode.org/issue/drupal-3410011/-/pipelines/70540

#10, I think the problem you are pointing it is a different issue. If I apply that patch to 10.2 without the fix in the MR the error described in this issue are still present.

I would say a new issue has to be created.

Yes, the commit of the error you mention was introduced in the MR of this issue when a rebase was done, adding all commits committed the dev branch.

So we are good here, and still RTBC-