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.)
Fixes the pathological handling of unmatched brackets, which could hang the
browser. Adds support for mailto: query params. Removes support for nested
parentheses in URLs, as these are rare. Adds comment with formatted version of
regex to make it easier to modify in future.
This was the only block-level element being rewritten, and could result in some
strange effects. For example, when you move a background colour from the <p> to
a <span>, it renders very differently. It was already inconsistent to do this
for <p> but not for <div>, and better just to drop it.
When converting <br>s to our preferred <div> style in fixContainer,
we don't want to use the default block style as that may change the
visual output. We always want to just use a basic <div>; the only
purpose is for line breaks.
If the rich text view is inside an overflow:scroll, every time you add a link
or do something else that requires we programatically focus the editor it would
jump the scroll back to the top; very annoying.
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.
