Editor since 2005; WMF developer since 2013. I work on Parsoid and OCG, and dabble with VE, real-time collaboration, and OOjs.
On github: https://github.com/cscott
See https://en.wikipedia.org/wiki/User:cscott for more.
Editor since 2005; WMF developer since 2013. I work on Parsoid and OCG, and dabble with VE, real-time collaboration, and OOjs.
On github: https://github.com/cscott
See https://en.wikipedia.org/wiki/User:cscott for more.
This caused a regression in Parsoid; two different patches above to resolve it.
Ok, this makes more sense that a JS interaction would cause memory exhaustion (vs just a particular magic sequence of HTML).
There's the potential to break various parser tests that hardcode a file URL. I don't think this will be a big concern in practice, but something to look out for.
It appears at the moment for these "html heading" tags we are wrapping them but not including them in the TOC, whereas we want to *not* wrap them but *include* them in the TOC.
A quick test seems to indicate that both Parsoid and the legacy parser use the .textContent of the HTML included in the heading to generate the TOC text (and presumably ID): https://en.wikipedia.org/w/index.php?title=User_talk:Cscott/Toc&oldid=1356567473
Does this trigger with using "desktop" mode on iOS Safari, but with useparsoid=1? My assumption is that this is a MobileFrontEnd bug, not necessarily a Parsoid bug.
This was a category breaking a wikilink, like:
[http://example.com/foo[[Category:Bar]].mp3 caption]
This is unsupported wiki syntax, that happened to work with the legacy parser because it stripped categories.