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
These shortcuts alter the indentation level of blockquotes. When inside a list this is probably not the behaviour the user would expect. This change alters the functionality to increase/decrease the list indentation level instead of wrapping the list item in a blockquote when inside a list.
Co-authored-by: Neil Jenkins <neil@nmjenkins.com>
With soft keyboards, e.g. on an iPhone, the shift key is automatically activated
when the cursor is at the beginning of the paragraph. However, this meant that
when you hit backspace, we were not handling the event and the browser was doing
it for us, resulting in broken styling.
If you backspace/delete to remove an uneditable block, we should be checking if
it's part of a larger uneditable container and if so removing the whole thing.
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.
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.
