Modal dialogue Views Messages breaks form usability

#23 Failed For 10.1x So Re-roll For 10.1x .

ccf fix #31

Uploading a 10x patch to (hopefully) stop the cycle of "custom commmands failed" attempts

@Prem Suthar @_pratik_ You can check for Custom Commands Failed locally without having to add noise to
the issue. Notice at the end of the fail report it says

Drupal code quality checks failed.
To reproduce this output locally:
* Apply the change as a patch
* Run this command locally: sh ./core/scripts/dev/commit-code-check.sh
OR:
* From the merge request branch
* Run this command locally: sh ./core/scripts/dev/commit-code-check.sh --branch 10.1.x

+++ b/core/modules/views_ui/tests/src/FunctionalJavascript/FilterOptionsTest.php
@@ -83,4 +85,34 @@ public function testFilterOptionsAddFields() {
+    $web_assert->waitForField('override[controls][options_search]');
+    $this->assertSession()->pageTextContains('Operating in maintenance mode. Go online.');
+    // Test that the both special fields are visible.
+    $this->assertTrue($page->findField('name[views.views_test_field_1]')->isVisible());
+    $this->assertTrue($page->findField('name[views.views_test_field_2]')->isVisible());

This test probably won't work because 1) the fields being checked for are not the last ones in the list (might work better to just look for :last-child). 2) The test theme Stark doesn't provide much height to messages area, so I'm not sure the bug can even be reproduced without a little extra css boosting the height.

Hiding files and updating credit

Why is a bug. Why are we targeting 11 and not 10.x?

I have the same in 10.2

11.x is the current development branch and has to land there first and then backported if applicable.

Why not target 10.x and then merge into 11.x?

@2dareis2d0 because that's how core changes are made according to policy: https://www.drupal.org/about/core/policies/core-change-policies/backport... → , and https://www.drupal.org/about/core/policies/core-change-policies/backport... →

If you disagree specifically with this policy, this specific issue is probably not a helpful place to have that discussion.

Ok I have rerolled the patch locally and seems to work well for me. Before and after pictures attached.

Not a hard requirement but recommended to use MRs as they are faster and easier to review. Drupalci is deprecated you'll see it doesn't auto run anymore.

hmm, if this happened it would not be an issue:

Committers commit patches to the main development trunk. The patch is then cherry-picked back to the stable branch(es). This ensures that there are no regressions from minor release to minor release.

I have recently seen a change merged into 11.x but it has not been cherry picked into 10.2 afaict.
e.g. https://www.drupal.org/project/drupal/issues/3332943 ✨ Claro - fix issues with icon sizes Needs work

The problem with MR's is there is no easy way to apply them afaict. Patches are tried and tested.

@2dareis2do you can get the patch for a merge request by appending .patch to the URL of the MR.

EG for https://git.drupalcode.org/project/flysystem_s3/-/merge_requests/15 you can get the patch at https://git.drupalcode.org/project/flysystem_s3/-/merge_requests/15.patch

Ok that's a good tip about the patches

Tasks and feature requests typically aren't backported. Bugs will be most of the time.

Any patch I create is on the latest stable branch where possible. I have never even installed 11.x, never mind created a patch for it.

For me this is clearly a bug so hopefully this will back ported. Why the policy is such still remains a bit of a mystery as it would seem to also make sense to do the opposite. i.e. when a new stable branch is created, cherry pick or even better merge into the next major dev release.

Updated patch for install via composer from web e.g.

        "patches": {
            "drupal/core": {
                "Modal dialogue Views Messages breaks form usability - https://www.drupal.org/project/drupal/issues/3161840": "https://www.drupal.org/files/issues/2024-01-03/project_drupal_issues_3161840b.patch"
            }
        }

test is failing due to running out of space. Will try running again.

DrupalCI is currently broken for core patches. You can convert to using a merge request instead.

Ok I have created an issue fork of 10.2.x. Not sure how to generate a MR?

https://git.drupalcode.org/issue/drupal-3161840/-/compare/10.2.x...31618...

Despite everything else appearing to be broken since before Christmas, I can confirm this patch does work.

The patch does not apply to 10.2.2

Works for me

The default branch for new work is 11.x. Anything done on 11.x also gets added to the next 10.x release unless specifically designated for 11.x.

Additional feedback is in the MR that should be addressed.