Bug 92771 – Applying suggested spelling correction eliminates leading space

• Status: UNCONFIRMED
• Component: HTML Editing

[Daniel Jalkut]

This bug was confirmed on built-from-sources WebKit as of today.

NOTE: I couldn't figure out how to write a test for this … I saw some examples having to do with autocorrect in the platform/mac section, but this bug only happens reliably for me if I spell-correct using the contextual menu to choose the replacement word. If anybody wants to offer advice for how to write a test I'll take another swing at it.

PROBLEM: Selecting and correcting the spelling of a word can eliminate the preceding space, causing the "corrected" word to merge with the previous word in the sentence.

To reproduce:

1. Open Safari's Snippet Editor.
2. Paste the following HTML:

<div contentEditable="true" spellcheck="true"><blockquote type="cite"><font face="Arial">what's happenin here?&nbsp;</font></blockquote></div>

3. Click into the editable web view and double click to select "happenin"
4. Right click the word and select the suggested fix: "happening"

Expected: The word should be corrected and continue to be separated from "what's" and "here" by spaces.

Actual: The content of the page changes to "what'shappening here?"

[Daniel Jalkut]

For what it's worth I just confirmed this bug is still happening on the shipping Safari in 10.10.1: Version 8.0.1 (10600.2.2).

[Daniel Jalkut]

I have determined that the problem is not strictly limited to spelling check replacements. The issue can occur as well when simply pasting a replacement string over a selected word, or a part of a word that is preceded by a space. The issue seems related to ReplaceSelectionCommand's special treatment of content inside of blockquotes, apparently for the sake of Mail.app. If I force m_ignoreMailBlockquote to true, the problematic behavior does not occur.

[Daniel Jalkut]

I see now that htmlEditing.cpp's "isMailBlockquote" function actually looks specifically for the blockquote possessing a type="cite" attribute, so this is pretty limited in its impact but it still seems like it would be nice to fix.

[Daniel Jalkut]

I found a comment in CompositeEditCommand::inputText that strongly suggests the bug I'm observing is already tracked in Radar #9914462. Apparently a known bad behavior of BreakBlockquoteCommand, which happens to get called from the scenario described in this bug but which obviously can be reached from other code paths as well:

// FIXME: Breaking a blockquote when the caret is just after a space will collapse the 
// space. Modify startIndex or length to compensate for this so that the ending selection 
// will be positioned correctly.
// <rdar://problem/9914462> breaking a Mail blockquote just after a space collapses the space