A map of capture groups to functions for producing the href of a
link. By default, it is e.g. used to prepend https:// to links
matching on www. so they are not interpreted as relative.
The user can add their own handlers if modifying linkRegExp.
Signed-off-by: Øyvind Rønningstad <ronningstad@gmail.com>
Solves/improves the following:
- Setting a custom linkRegExp messes with the logic for adding
protocol or mailto. Use named capture groups in the regex, and
add a case in the href generation that just uses the match
directly if neither the url nor the email regex matches, which
would mean that the user's custom regex matched instead.
- Make https the default protocol instead of http
- Use a more general regex for matching the protocol.
Signed-off-by: Øyvind Rønningstad <ronningstad@gmail.com>
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
