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:
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:
the behaviour is:
<ul>
wrapper with<li>
elements inside. Tab B has a<ul>
wrapper for its list.* a
appears as plain text, followed by a properly rendered<ul>
list withb
andc
. This behaviour is fairly consistent elsewhere, so for the simplicity of handling this issue we can consider it correct.* a
is rendered as a plain text paragraph (first regression). This is immediately followed by a correct<ul>
list withb
andc
.* a
is rendered as a plain text paragraph. List elementsb
andc
are rendered without a<ul>
wrapper (second regression). The output looks like<p>* a</p><li>b</li><li>c</li>
.* a
is rendered as a plain text paragraph, as expected. However, list elementsb
andc
are rendered without a<ul>
wrapper (second regression). The output looks like<p>* a</p><li>b</li><li>c</li>
.<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: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)