I came upon a table that chokes the linter in CM, sending its memory usage to over 3GB in Firefox (Linux).
To reproduce, edit https://test.wikipedia.org/wiki/Linter_choker with th CM linter on. It's good to have about:performance page on to be able to kill the tab where the editor is open. Careful, this could make your whole browser crash.
It seems that the second line in the following code does it:
{| class="wikitable"
'''Pobjednici po kotarima
|-| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| CodeMirrorMediawiki: Parsoid errors | Bhsd | mediawiki/extensions/CodeMirror | master | +8 -6 |
Change #1310233 had a related patch set uploaded (by Bhsd; author: Bhsd):
[mediawiki/extensions/CodeMirror@master] CodeMirrorMediawiki: Parsoid errors
Parsoid can sometimes compute bad source offsets for bad markup -- especially tables where content can get fostered out which completely messes up the ordering of content compared to the original source. So, clients should have some sanity checks.
For this example, the output looks like this:
<p data-parsoid='{"fostered":true,"autoInsertedStart":true,"dsr":[0,0,null,null]}'><b data-parsoid='{"autoInsertedEnd":true,"dsr":[21,0,3,0]}'>Pobjednici po kotarima</b></p><table class="wikitable" data-parsoid='{"autoInsertedEnd":true,"dsr":[0,50,20,0]}'>
<tbody class="mw-empty-elt" data-parsoid='{"dsr":[47,50,0,0]}'><tr class="mw-empty-elt" data-parsoid='{"startTagSrc":"|-","dsr":[47,50,2,0]}'>
</tr></tbody></table>So, the <b> tag is embedded inside a <p> tag which has a "fostered" marker. Perhaps Parsoid could clear the dsr info for all embedded content in those foster boxes if it looks bogus.
Change #1310233 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] CodeMirrorMediawiki: Parsoid errors