The content should be safe anyway as it will already have been sanitised,
however mXSS attacks are still a slight risk so safer to always run it through
the sanitiser.
The previous workaround no longer works. You still can't use removeAllRanges
(that closes the keyboard too), but we can use the setBaseAndExtent API instead.
It must be plain text if they're the same, and this helps avoid a Safari bug
(when we can) where when you copy HTML and then paste it in Pages/Numbers, it
gets the charset wrong and mangles non-ASCII characters.
Previously ctrl+shift+{7,8} would make an (un)ordered list but
hitting the shortcut again would have no effect. This change
causes the list to be removed when triggering the shortcut while
inside the list.
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.
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.
