No error messages are shown for applied validation on a view exposed filter with on "AJAX"

Added coverage for inline form errors, this fails without the disable_inline_form_errors line. Also fixed the expected message, added :void

It seems like all failures similar to #49 in core are already ignored so this is my best guess at something that will work for us.

The last submitted patch, 50: 2977785-50.patch, failed testing. View results →

Fixed the error in #53 patch.
Please review.

Tried to fix CCF on #53

The new tests got lost in #53, please add them back in

Add the Tests As Per #55 Suggestion. try To Fix failed test.

The correct fix is to not let ViewAjaxControllerTest return NULL for renderRoot. There was already a mock for render which isn't even called in that test, so we just replace that mock with renderRoot

Confirmed the issue following the steps in the issue summary.
Using patch #57 I now get an error.
There are no users matching "asfsd".

Changes look good.

Think I agree with @acbramley

If there's room for refactoring the standard of AJAX status messages maybe that should be a follow up?

The last submitted patch, 57: 2977785-57.patch, failed testing. View results →

ViewsFormBase is wrapped by \Drupal\views_ui\Form\Ajax\ViewsFormBase::ajaxFormWrapper as far as I can see, and that does the executeInRenderContext dance.

Status messages is placeholdered so in Big pipe scenarios could require JS, additionally anyone could in theory alter #cache/#attached in a hook_preprocess_status_messages.

However looking \Drupal\Core\Ajax\CommandWithAttachedAssetsTrait::getRenderedContent it looks like if you pass in an array it will take care of getting the attached libraries and rendering, so can we just pass ['#type' => 'status_messages'] as the content to the prepend command? Would simplify things a lot I think so it's worth a shot I think.

@larowlan that does work! So much cleaner.

The last submitted patch, 68: 2977785-68.patch, failed testing. View results →

Need to mock getInfo on the element manager now since way down the stack that is called with the new method of passing in an array.

Retested following steps in issue summary.
Patch #70 still addresses the issue.

Can we get an answer for #41 or alternatively @Lendude can you confirm they're not needed?

Adding issue credits

I think we already have it when pageTextContains was changed to pageTextContainsOnce, basically what I was looking for was something that would fail if somebody removed $form['#disable_inline_form_errors'] = TRUE;, and if the comment above that line is correct, that should do the trick.

So this looks good to me, nice work all!

Committed to 10.1.x and backported to 10.0.x

Queued a test run for 9.5.x, will backport there if it passes.

9.5 run came back green, backported to 9.5.x - marking as fixed 💪

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

Is there a patch available for drupal 8.9? I can't seem to find one. The one for version 9 isn't working for me.