The previous test was incorrect. A <br> actually introduces a line break if
there is any non-whitespace after it in the block or if there is another <br>
after it in the block. It is irrelevant what comes before it in the block.
IE and Safari 5 loses the selection during the bookmarking process, so we must
always explicitly reset the selection after recording an undo state (which adds
a bookmark).
When cleaning up <br>s, if it's inside a block we can't split, it's probably a
containing node (like a <blockquote>), so we should wrap the top level inlines
instead.
* Odd bug this. From the logs, it seems either it's returning a range with no
startContainer, or the startContainer is not something inheriting from the
Node prototype (which would be very wrong).
When cleaning up <br> elements, we need to accurately determine whether there's
text before and after it in the block to know whether it will introduce a
visible line break.
* But only if it's deleting whitespace or destroying a block or deleting a
selection. This makes it undo deletion word-by-word rather than
character-by-character.
Previously, we were just removing <br>s that didn't have siblings on both sides. A better test is whether the containing block has any non-whitespace text content. If it does, the <br> is a line break and we can just split the block. If it doesn't though, we need to leave the <br> as a placeholder, to ensure the block doesn't collapse to 0 height.
* When cleaning the tree we want to remove useless whitespace between block
nodes, but we were being a bit too aggressive and removing all whitespace
nodes. Now checks the context first.
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.
Won't throw an error if called on a node that is not part of a document, but
will now instead return the path from whatever the root element is down to the
node.
* 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.
When restoring a range from a bookmark, always call range.moveBoundariesDownTree
to anchor it to the nearest text node. If you call setSelection with a range not
anchored inside a textnode, Opera may incorrectly set the selection.
A willPaste event is now fired just before pasted content is inserted into the
document, allowing custom, arbitrary modification of the pasted content, or
prevention of the paste event altogether.
If the node containing the zero-width space character was merged by a call to
Range#mergeInlines, the character was not being removed, making for odd cursor
movement.
