Toggling a code block off can leave its text directly on the editor root instead of wrapping it in a block. If the caret is then inside that text, block commands silently do nothing because getStartBlockOfRange cannot find a block and returns early.
For example:
editor.setHTML("<p>one</p><p>two</p>");
// caret in the first paragraph
editor.toggleCode(); // <pre>one</pre><p>two</p>
editor.toggleCode(); // one<p>two</p>After the second toggleCode(), "one" is a bare text node on the editor root.
removeCode() already calls fixContainer on the <pre> before replacing it with its children, which seems intended to wrap those children in blocks. But fixContainer returns immediately because of this guard in MergeSplit.ts:
/^(?:TABLE|TBODY|TR|TH|TD|P)/
Because the regex has no end anchor, PRE matches the P alternative. PICTURE and PROGRESS match as well.
Changing it to:
/^(?:TABLE|TBODY|TR|TH|TD|P)$/
looks safe to me. P still matches exactly, so the existing parsing behavior should be unchanged, while <pre> is allowed through fixContainer.
Seen in 2.4.8 and current master.
Toggling a code block off can leave its text directly on the editor root instead of wrapping it in a block. If the caret is then inside that text, block commands silently do nothing because
getStartBlockOfRangecannot find a block and returns early.For example:
After the second
toggleCode(),"one"is a bare text node on the editor root.removeCode()already callsfixContaineron the<pre>before replacing it with its children, which seems intended to wrap those children in blocks. ButfixContainerreturns immediately because of this guard inMergeSplit.ts:/^(?:TABLE|TBODY|TR|TH|TD|P)/Because the regex has no end anchor,
PREmatches thePalternative.PICTUREandPROGRESSmatch as well.Changing it to:
/^(?:TABLE|TBODY|TR|TH|TD|P)$/looks safe to me.
Pstill matches exactly, so the existing parsing behavior should be unchanged, while<pre>is allowed throughfixContainer.Seen in 2.4.8 and current
master.