Steps to reproduce: 1. Open a web page (like this bug!) with a text area. 2. Type in "asdf". 3. Select all and copy "asdf" to the clipboard. 4. Position the cursor between "as" and "df". 5. Hit Cmd-V to paste. Expected results: "asasdfdf" Actual results: "aasdfsdf"
The cause of this problem is this code in ReplaceSelectionCommand::doApply: if (!isEndOfParagraph(visibleStart) && !isStartOfParagraph(visibleStart)) { insertParagraphSeparator(); setEndingSelection(VisiblePosition(endingSelection().start(), VP_DEFAULT_AFFINITY).previous()); } It seems crazy to me that we always insert a paragraph separator for any paste. But given that we try to do so, there are problems with this code. The main problem is that insertParagraphSeparator is not guaranteed to insert anything. There are two cases where it won't, as you can see by readingInsertParagraphSeparatorCommand::doApply. For example: 1) If we're in an empty list item, we will break out of the list. 2) If the startBlock has no parent node, we will do nothing. In this bug the case is (2). The fix could be as simple as changing the startBlock->parentNode() case to create a new block that's a child of startBlock or to use InsertLineBreakCommand the way the isTableCell case does.
Created attachment 9026 [details] patch that fixes the bug, no layout tests, no change log, may not be best fix
(In reply to comment #2) > Created an attachment (id=9026) [edit] > patch that fixes the bug, no layout tests, no change log, may not be best fix > I would fix "2) If the startBlock has no parent node, we will do nothing" to fix this. Also, I think that "1) If we're in an empty list item, we will break out of the list." should only be default behavior for the InsertParagraphSeparatorCommand that results from a keypress. Add a bool to its constructor.
<rdar://problem/4613519>
*** Bug 9790 has been marked as a duplicate of this bug. ***
r15528