The core/drupal.message library requires a status_messages render element

This causes the problem in 🐛 Exceptions in batch no longer are shown on the page: Javascript error Fixed

I put a fix in 🐛 Exceptions in batch no longer are shown on the page: Javascript error Fixed . This doesn't solve the problem of the library requiring the status_messages render element but it does allow putting that render element on the page without it automatically rendering the service side messages.

The needs of the batch page is that messages the server knows about should not get rendered on this page but if there are ajax calls that results in errors these should be rendered on the page(at least to keep the pre-existing functionality).

Tagging this as Automatic Updates Initiative because we need have error messages on the batch page for Automatic Updates. Otherwise if we did beta testing and users couldn't easily see these error the testing would be much less useful.

So we could solve in the way I did in 🐛 Exceptions in batch no longer are shown on the page: Javascript error Fixed or another way here or maybe a temp fix in the AutoUpdates module itself would be ok like we did here 🐛 Ensure that errors are shown on form updates in core 10.1.x Fixed

In any case we have to solve it someway to get Automatic Updates into core so bumping this to Major

Funny, just ran into this and saw you recently commented ;D

It's not yet totally clear to me yet, what the change was, that caused this. Technically, we need [data-drupal-messages] or [data-drupal-messages] to be present on the page. But if not, it should be added by JS?

My concern with other solutions is, that they may also rely on custom configuration or theme implementations, which we can't really rely on?

I think I am seeing this too, in Drupal 10. When running a migration, if it tries to output a message (e.g. an error), it causes the batch page to break due to a console error: wrapper is null.

static defaultWrapper() {
  let wrapper = document.querySelector('[data-drupal-messages]');
  if (!wrapper) {
    wrapper = document.querySelector('[data-drupal-messages-fallback]');
    wrapper.removeAttribute('data-drupal-messages-fallback');
    wrapper.setAttribute('data-drupal-messages', '');
    wrapper.classList.remove('hidden');
  }
  return wrapper.innerHTML === ''
    ? Drupal.Message.messageInternalWrapper(wrapper)
    : wrapper.firstElementChild;
}

There is no such element on the page with data-drupal-messages or data-drupal-messages-fallback attributes. I would guess the error was introduced in #77245: Provide a common API for displaying JavaScript messages → .

see MR

Could the issue summary be updated some please. Mainly proposed solution. Assuming not a UI or Data model change.

Also tagging for tests as mentioned in the summary

wasn't notice because there not tests for errors showing up on the batch page

Also

core/modules/system/tests/src/FunctionalJavascript/Batch/ProcessingTest.php

test was added in https://www.drupal.org/project/drupal/issues/3406612 🐛 Exceptions in batch no longer are shown on the page: Javascript error Fixed issue with a temporary fix which is now removed and replaced with a concrete JS fix.
If Still there is a requirement for adding test I am happy to do that.

So if I understand correctly this is more about refactoring a temporary solution into a better one, in that case believe task is probably more right category.

Removed the tests tag per #18, if this solution isn't doing anything new then agree probably doesn't need additional coverage.

Thanks for updating the issue summary removing that tag.

Looking at the change and update seems simple enough and didn't break any existing coverage.

Couple of things to simplify then it's good to go, thanks!

you need to keep

        wrapper.removeAttribute('data-drupal-messages-fallback');
        wrapper.setAttribute('data-drupal-messages', '');

outside the if (!wrapper)

Feedback appears to be addressed.

nod_ → closed merge request !8294

Committed and pushed bff71e54fc to 11.x and 653c57335b to 11.0.x and 03f71c7351 to 10.4.x and dfbffd2a19 to 10.3.x. Thanks!

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