A number of places (cf https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/462753/10/includes/FileDeleteForm.php) contain a pattern like:
$wgOut->addWikiTextAsInterface('<div class="error">' . $something . '</div>');Of course, (a) this breaks if $something has an extra </div>, and (b) the $something gives up its start-of-line context in an unpredictable way (something the pattern has a newline after the opening <div>, sometimes it doesn't).
It would be better to introduce a new interface which uses the (robust) wrapping functionality of ParserOutput instead:
$wgOut->wrapWikiTextAsInterface('error', $something);Since the output of parsing $something is tidied by the addWikiTextAsInterface method, this would ensure that the wrapper is robust.
A related problem is placed which do addWikiTextAsInterface("<p class=....>$something</p>"). This is even more fragile, since a double-newline or a <div> will break the wrapper.
A few instances wrap calls to Html::errorBox, like:
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/462753/10/includes/page/Article.php
but as far as I can tell no one uses the $heading option to errorBox, so these should be straightforward to replace with $wgOut->addWikiTextAsInterfaceWrapped( 'errorbox', ...)
There's also an OutputPage::wrapWikiMsg() function with similar functionality; it would be nice if it could be made safe, for example by parsing the content in a tidy safe and *then* composing it with the wrapper. We could deprecate the case where the first argument contains a "$1", and then treat other strings as wrapper classes (like wrapWikiTextAsInterface) and perhaps accept an array of attribute->value mappings for more advanced wrapping -- the common case seems to be to add dir and lang attributes in addition to the class.