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.
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.
If the content hasn't changed before an undo point is requested we ignore the
request, but the cursor position may have changed and users expect undo to
restore the cursor position immediately before the requested change was made.
So in this instance we now still record an undo state, but replace the previous
one if the content is unchanged.
The selectionchange event handler can only be registered on the document
but we are not interested in changes of focus/selection that happen
outside of the editor, so check we have focus before firing the update
path event.
ms html clipboard format CF_HTML handles table like below if we copy part of table.
it makes problem when copying table from ms product such as ie, excel, powerpoint then pasting to squire.
<TABLE BORDER>
<!--StartFragment-->
<TR><TD>Item 6</TD><TD>Item 7</TD></TR><TR><TD>Item 10</TD><TD>Item 11</TD></TR>
<!--EndFragment-->
</TABLE>
and
<TABLE BORDER><TR>
<!--StartFragment-->
<TD>Item</TD>
<!--EndFragment-->
</TR></TABLE>
https://msdn.microsoft.com/en-us/library/windows/desktop/ms649015(v=vs.85).aspx#274
If an action modifies the selection while the editor is not focused, we cannot
immediately set it in the DOM as this triggers focus. So instead we cache it and
restore on focus. If getSelection is called before the editor is next focused,
we need to return this new selection, not the current DOM selection.
Fixes#259
* Data added to clipboard should now always be the same for cut as for copy
* Fixes bug when cutting across blocks, where not all parents would be included
in the data added to the clipboard
1. Fixes cursor position when deleting starting with a selection at beginning
of block.
2. Fixes block disappears when whole inline contents is deleted.
