The fixer node may get removed when merging adjacent inlines, so move
the cleanup to before this. For safety, also properly check for non-null
nodes so we don't crash if it's still elided for some reason.
There seems to be a bug in Chrome where it will sometimes not render
some of the text in the DOM when there are multiple zero-width spaces
around the beginning and ends of inline tags (not sure on the exact
details).
Steps to reproduce (prior to this commit):
1. Turn on bold and underlined text
2. Type something in bold and underlined text
3. Turn off bold and underline
4. Try to type something — it will not show up! That is, until you press
the enter key and we remove the zero-width spaces.
If extractRangeToClipboard was called with a toPlainText fn and
plainTextOnly=true, and there was a selection that was not just inside
a single text node, it was not actually getting the text to add to the
clipboard.
Instead of using innerText, this now uses the getTextContentsOfRange
helper fn to work out the white space, so is consistent with the
editor's getSelectedText method and should be higher fidelity.
Note, you can still override the behaviour by supplying a toPlainText
fn in the editor config (such as the one you can find at
https://github.com/fastmail/overture/blob/master/source/html/toPlainText.js)
On Chrome, if you made an inline formatting change, this would insert a
new <span> with a ZWS inside so we could focus it. Pressing Space would
remove this ZWS resulting in the focus ending up outside and so the
formatting would be lost. We were removing the ZWS so we could check
if we were at a block boundary correctly; instead, I've made it so the
boundary check can handle trailing or leading ZWS (see previous commit).
We were looking at the selection properties after we had mutated the DOM, and
trying to manipulate them based on some numbers cached from before mutating
the DOM, which could result in trying to set a negative index for the selection
offset. Instead, calculate all our values before we do any mutations.
Fixes#430
This is a massive refactor to port Squire to TypeScript, fix a bunch of small
bugs and modernise our tooling. The development was done on an internal
repository, so apologies to anyone following externally for the commit dump;
updates from here should come as real commits again.
Co-authored-by: Joe Woods <woods@fastmailteam.com>
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.
