Incorrect list handling results in wonky editting in browser after API method setHTML called with list items

[timtebeek]

Also see: Pita/etherpad-lite#768

When a <ul>-list is present in the HTML fed into setHTML, all content after that list is also marked as part of the list in the browser (at least in Google Chrome & Firefox), while the server side correctly retains the content fed in setHTML. This makes the editting in the browser to behave inconsistently, as the browser representation is different from the server side content: The cursor will shift, wrong lines will be removed when using backspace, and there is no way to restore the pad to a consistent state.

One can reproduce this problem by using this link:
https://localhost:9001/api/1/setHTML?apikey=secret&padID=test&html=%3Cdiv%3E%3Cul%3E%3Cli%3Eitem%201%3C/li%3E%3C/ul%3E%3Cbr/%3Efurther%3Cbr/%3Econtent%3Cbr/%3E%3Cbr/%3Ealso%20indented%20%3C/div%3E

Can someone look into this issue? One really can't edit the pad sensibly anymore if a list was present when the content was imported.

[marcelklehr]

I believe this is fixed with #773 pulled?

[timtebeek]

Nope, issue still remains... Even though getHTML returns the correct content, the browser state is messed up.

Tested with <div><ul><li>item 1</li></ul><br/>further<br/>content<br/><br/>also indented</div>

[jhollinger]

This seems to be an issue with the jsdom library (or maybe how we're using it?) Using jsdom doesn't really make sense, since we're only using it for parsing. We may want to look at http://github.com/robrighter/node-xml or https://github.com/astro/node-expat instead. Researching...

[timtebeek]

Any progress on this issue? I'm waiting for a fix before I can cleanly migrate pads between two Etherpad-lite instances.

If a fix is not expected anytime soom please let me know: In that case I'll just migrate the database contents between the two instances.

[odony]

I don't think the problem lies in jsdom or its use. It seems it was introduced by 6507614 during a change of line attributes processing. state.listType was replaced by state.lineAttributes but is not handled identically wrt to the list type. There are multiple ways to fix it, one would be to change _exitList() to properly delete state.lineAttributes['list'] when exiting back to the none list type.
I'll try to make a pull request with a fix.