List rendering behaviour regressed between 1.7.5 and 1.8.0

This week at wiki.gg we have deployed TabberNeue 1.9.1 alongside MediaWiki 1.41, but some of our wikis are now facing issues with list rendering in tabbers when wikitext list markers *, ;, :, # are at the very start of a tab.

Reproduction

For a test page of:

<tabber>
a=
* a
* b
* c
|-|
b=
* a
* b
* c
|-|
c=* a
* b
* c
|-|
d=<div>
* a
* b
* c
</div>
</tabber>

the behaviour is:

Before 1.8.0 (this is the expected behaviour that is most intuitive):
- Lists are properly rendered in tabs A, B, D, with a proper structure of a <ul> wrapper with <li> elements inside. Tab B has a <ul> wrapper for its list.
- In tab C, * a appears as plain text, followed by a properly rendered <ul> list with b and c. This behaviour is fairly consistent elsewhere, so for the simplicity of handling this issue we can consider it correct.
In v1.8.0, v1.9.1, v2.2.2 (incorrect behaviour):
- In tab A, the first line * a is rendered as a plain text paragraph (first regression). This is immediately followed by a correct <ul> list with b and c.
- In tab B, the first line * a is rendered as a plain text paragraph. List elements b and c are rendered without a <ul> wrapper (second regression). The output looks like <p>* a</p><li>b</li><li>c</li>.
- In tab C, the first line * a is rendered as a plain text paragraph, as expected. However, list elements b and c are rendered without a <ul> wrapper (second regression). The output looks like <p>* a</p><li>b</li><li>c</li>.
- In tab D, all list elements are rendered inside a <div> but with no <ul> wrapper. The output looks like <div><li>a</li><li>b</li><li>c</li></div>.

Possible cause

After bissecting, the commit at fault seems to be a3212b6c2b62a12b6cc0ca68a380b9f3c6a6b91b, specifically trimming the tab body seems to be causing both regressions. The first regression is most likely due to lists not being expanded inside of recursiveTagParse, therefore outputting <article ...>* a\n* b\n *c</article> instead of <article ...>\n* a\n* b\n* c</article>.

Second regression is a wikitext parser bug (one we have encountered before in a very different context), where parser's block-pass state is not updated to close a list if a different prefix (other list type) or a new line are encountered before the next list begins. However, this behaviour would also happen on rare occasions in v1.7.5 and before.

Proposed patch

Instead of $tabBody = trim( $tabBody ), perhaps doing $tabBody = "\n" . trim( $tabBody ) will help with the first issue.

For the second regression, Tabber::buildTab should add a new line character after the article element is closed:

        return '<article class="tabber__panel" data-mw-tabber-title="' . $tabName .
-       '">' . $tabBody . '</article>';
+       '">' . $tabBody . "</article>\n";

This will, however, result in test tab C with the entire list parsed. Probably not a huge deal (and in the past I considered that example a bug).

(We'll be rolling with these two changes until an official patch is ready. For my wiki.gg teammates' reference, internal ticket is WIKIDEV-156)

StarCitizenTools / mediawiki-extensions-TabberNeue