When links are pasted into the editor the cursor ends up at the
end of the text node inside the parent <a> element. Any text
entered is then appended to the end of the link text. Chrome
automatically moves the cursor after the end of <a> elements when
additional text is inserted, so this change enforces the same
behaviour in other browsers.
Resolves LP 55607264
https://app.liquidplanner.com/space/14822/projects/show/55607264
If you have a document like this:
<div style="font-size:20px">XXXX</div>
<div style="font-size:14px">YYYY</div>
and you select the YYYY text and copy it, we just copy the text to the clipboard
and not the block formatting. This is fine.
Now you select XXXX and paste. Because that removes all content from the first
block we were replacing it with the block formatting from the clipboard. But
this has no block formatting, so you essentially just "lost" the font-size:20px,
which broke user expectations.
(If the copied text *did* have block formatting, then replacing the block is
the correct thing to do in this case, which we still do.)
If the clipboard contains block contents, e.g.
<blockquote><p>Foo</p></blockquote>
Then if you paste it into a block that already has content we merge the inline
content from the first block and discard its surrounding block.
However, if you paste into an empty block, we'll now keep the block and remove
the empty one in the document. This seems a reasonable heuristic for determining
user intent.
1. Fixes cursor position when deleting starting with a selection at beginning
of block.
2. Fixes block disappears when whole inline contents is deleted.
* In browsers that support it, we now tell it to copy exactly what was selected
in the DOM, and not to add extra gunk which browsers do to preserve exact
styling if pasted into another document.
* Don't use the clipboard APIs with MS Edge, since it only supports plain text.
If we let it fallback to the browser implementation it will insert HTML.
If the selection starts and ends in the middle of blocks, we need to merge
these after extracting the range. But we need to be careful not to merge if
the selection ends at a block, as we end up merging into a block that wasn't
selected.
Pasting is hard to get right in the general case, not least because the
browsers give so little control over the process, leaving you to resort to
crappy hacks. But we can special case the pasting to a blockquote case fairly
easily, and I can't see any particular regression it should cause.
Fixes#59.
Just return a boolean for the TreeWalker filter fn. This diverges from the spec,
but since the goal of this implementation is not to fully implement the spec
and we're never going to use a native implementation, this doesn't matter and
the code is easier to read when the function is just returning a boolean like
any normal filter function.
Merging containers could remove the nodeAfterSplit from the tree, which then
caused an error to be thrown if it had no content, as the code would try to
remove it again.
* Do not move range boundaries inside images; these should always be treated as
leaf nodes.
* Workaround FF bug where it may return range as being inside of image node.
