Page MenuHomePhabricator

VisualEditor: Leading newlines in <pre>s get eaten
Closed, ResolvedPublic

Details

Reference
bz42469

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:00 AM
bzimport set Reference to bz42469.
Catrope created this task.Nov 27 2012, 1:43 AM

Mark and I looked at this and discovered it was because VE round-trips the HTML in question through the browser's HTML parser, which turns "<pre>\n" into "<pre>". Shockingly, this is actually mandated by the HTML spec.

We can work around this in the converter by setting a flag on these pre's on the way in and checking for it on the way out.

(In reply to comment #1)

We can work around this in the converter by setting a flag on these pre's on
the way in and checking for it on the way out.

...or not, grah. Because of the way the DOM API works, I have no way of detecting this from within a browser.

The approach we're taking now is that VE will work around this in cases where there are semantically meaningful newlines in the <pre> (i.e. >=1 newline read from the DOM) by adding a newline. That only leaves the ambiguity between <pre>Foo</pre> and <pre>\nFoo</pre> , which is syntactic, not semantic, and will be handled by Parsoid using round-trip data.

The VE portion of this is fixed in https://gerrit.wikimedia.org/r/36692 . The Parsoid portion of this is bug 42666 and bug 42667.

Parsoid fixes have landed, issue confirmed fixed in VE as well.