Spellcheck spans are modifying document HTML

[winhamwr]

Under some common condition (it's happened in 3 out of 3 edited PolicyStat documents I've checked so far), spell check modifies the HTML, even if the user doesn't use the spellcheck suggestions.

The goal should be to not alter HTML structure. My guess is that the structure is also altered when you accept a suggestion, but I didn't test that.

Some examples of HTML before editor load and then the resulting HTML after the document was saved:

First word spelling suggestion

• <strong>Wes Q3</strong>
• <strong>Wes</strong><strong> Q3</strong>

  Last word spelling suggestion

• <a href="https://policystat.zendesk.com">Site to Site VPN</a>
• <a href="https://policystat.zendesk.com">Site to Site </a><a href="https://policystat.zendesk.com">VPN</a>

  First word again, with a tag

• <a href="support.policystat.com">PolicyStat Learning Center</a>
• <a href="support.policystat.com">PolicyStat</a><a href="support.policystat.com"> Learning Center</a>

[caffodian]

I think the surrounding HTML matters, but I'm not sure how yet. The best thing to do is probably to start with the whole p tag as test data.

<p><strong>Josh &amp; Gabe</strong> - started process of eliminating the traditional &quot;Sales Transition Call&quot; then IC team met to refine and establish new Kickoff call guidelines.</p>

Gets mangled.

My attempt at typing "Josh & Gabe" into bold text, then saving and refreshing - didn't mangle the strong tag. Same with various other attempts at good word followed by typo, or ampersand + space followed typo, all inside strong tags.

[winhamwr]

This behavior would interact pretty badly with the autoid stuff (if h# tags are impacted). If a heading got split in two, we'd have ID confusion.

[sbaughman]

I've tracked it down to wrapTypoWithSpan function. When the range contents get extracted for insertion into the created typo span element, the range collapses and somehow the subsequent insertion of the span causes a split in the outer tag.

This only occurs when the text being wrapped is directly against the closing tag. It also does not happen if there is no additional content after the closing tag.

No solution yet, but making progress

[sbaughman]

Update: so it's actually a consequence of how CKEDITOR.dom.range.extractContents works

[winhamwr]

We've decided that we have to be OK with some level of mutation, unless we want to fight very hard against CKEditor internals. We don't want to do that.

25 and #27 (I think) mitigated some of the worst-case examples of this, where we could.