Do not replace <-- --> and other certain characters in Markdown/HTML

[rugk]

Bug description

Let's take our issue templates here that make a lot of use of HTML comments, i.e. -->.
I was confused when editing issues here that some of my comments

Steps to reproduce

1. Use the add-on and write text on GitHub.
2. Edit the issue again or just write a HTML comment like <-- todo -->.

Actual behavior

The comment is converted to this:
⟵ todo ⟶.
Especially in a non same-width text like on GitHub here (⟵ todo ⟶) this is really subtle to spot and breaks the whole text as much of it is now commented, as the comment never ends.

Expected behavior

Replacing this with an arrow (⟵, ⟶) is never intended here, so a workaround would be good to find here.
It must not replace this.

System

Operating system and version: Linux/Fedora 33
Browser and version: Firefox 83
Add-on version: bb913b0

Further comments

The same applied maybe to ---- for making a horizontal line in Markdown, it is also replaced and thus breaks Markdown.

Possible solution

• scan for a beginning <--?
• detect that this is code/Markdown somehow and do not do autocorrections in here? (e.g ignore same-width font-sized text e.g. as in the code editor on MDN. Of course, this would not fix GitHub e.g.)
• have some blacklist (for a start may even be hardcoded and not configurable) to disable the feature on a website or disable only certain characters

[tdulcet]

Edit the issue again or just write a HTML comment like <-- todo -->.

Note that HTML comments are <!-- todo -->, so only the --> would be replaced with an arrow. As you know, users can always press backspace (⌫) to undo any unwanted autocorrections.

• scan for a beginning <--?

This would be tricky to implement, as you would need to detect any preceding <!-- that does not have a corresponding -->.

• detect that this is code/Markdown somehow and do not do autocorrections in here? (e.g ignore same-width font-sized text e.g. as in the code editor on MDN. Of course, this would not fix GitHub e.g.)

Yeah, you could detect if the user is typing in a code or pre element and disable autocorrections, similar to what Slack does, although this would only work with ContentEditable inputs that do not use custom elements.

[rugk]

Oh of course <!-- instead of <--, but you got my point. 🙂
So seems like the last thing would be a possible workaround for now? Or do you have any other idea? Maybe we could provide an option to disable it?

[tdulcet]

So seems like the last thing would be a possible workaround for now?

Yes, that would be a possible workaround for most websites. Although like you said, it would have no effect on GitHub since it uses textarea.

[rugk]

Yeah, you could detect if the user is typing in a code or pre element and disable autocorrections

So… @tdulcet do you think that’s a good solution then to implement?

Given it won’t work on GitHub (also not in the text editor), we have a huge user base of devs and so on there, which will definitively be annoyed by that “feature”, so hmm… I'm not sure.

[tdulcet]

So… @tdulcet do you think that’s a good solution then to implement?

Sure, we could add this as an option at least, probably disabled by default. Although I am not sure how difficult this would be to implement or if it would have any performance impacts.

Given it won’t work on GitHub (also not in the text editor), we have a huge user base of devs and so on there, which will definitively be annoyed by that “feature”, so hmm… I'm not sure.

We could also allow users to blacklist domains/websites, although disabling autocorrections on all of GitHub would obviously not be a good solution either. This would also require TinyWebEx/AutomaticSettings#15.