All batch labels are HTML escaped

We probably shouldn't be autoescaping the HTML in the init message (the render array is in _batch_progress_page()):

    // Base and default properties for the batch set.
    $init = array(
      'sandbox' => array(),
      'results' => array(),
      'success' => FALSE,
      'start' => 0,
      'elapsed' => 0,
    );
    $defaults = array(
      'title' => t('Processing'),
      'init_message' => t('Initializing.'),
      'progress_message' => t('Completed @current of @total.'),
      'error_message' => t('An error has occurred.'),
      'css' => array(),
    );
    $batch_set = $init + $batch_definition + $defaults;

    // Tweak init_message to avoid the bottom of the page flickering down after
    // init phase.
    $batch_set['init_message'] .= '<br/>&nbsp;';

I can't reproduce this, the init message is unescaped for me on HEAD

I did manage to reproduce this in the end. There is actually some JS replacement in progress.js, where it does $('div.progress__description', this.element).html(message);. So it really is just a flash.

Here's an attempt at a patch...

+++ b/core/includes/batch.inc
@@ -150,6 +155,7 @@ function _batch_progress_page() {
+    $message = Xss::filter($message);

Nice to see it becoming a render array. Just curious, why do we need the $message to be escaped with Xss::filter? Isn't that the default behaviour of '#markup'?

Hmm you're right. #markup does admin XSS escaping which may be enough here assuming it's only admin users who ever see a progress bar. So maybe this could be a 1 line fix.

This could use some tests if possible but I think you can fairly assume that the message wouldn't need markup beyond what Xss admin filtering allows.

Added a test

reverting a change from that last patch

And if you disable javascript it's not just on the initial step, but everywhere:

I reported this earlier in #2443005: Html displayed as text in installer initial batch operations message

Looks good to me.

RTBC++

The error handling also uses a <br /> tag in two different places - do you know whether this is also double escaped?

Also wondering whether there's something simple we can do to just ditch the hardcoded <br /> altogether.

We should ditch most <br />tags but for this one I'm not sure how or what it's purpose is. Some CSS trickery on the .progress__description may be possible, but IMO it's out of scope here as it's much less of an issue than the HTML escaping, where all labels are affected (not just the &nbsp;<br /> thing), and many of them have markup which also gets escaped (ie. #18).

As to the <br /> from the batch error handler, I tested and it's not double escaped:

The linebreak there is easier to get rid of, we can just wrap each error message in a block-level element instead.

The other bit is JS so unrelated.

Clarifying in the IS that this does not just affect the installer.

Makes sense. Opened #2555567: Remove hard-coded <br /> from batch API in case anyone wants to look at the break tags.

Committed/pushed to 8.0.x, thanks!