We merge a faux block with contents from after a split point when
inserting HTML. The merge function presumes this block has already had
fixCursor run on it to ensure we add the <br>s some browsers need to
support correct cursor focusing.
Fixes#451
The parent variable was introduced in the Typescript refactor to make
the type checker happy, however we missed assigning the result back to
the `node` variable at the end.
Fixes#449
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
