Emoji in markdown for specific patterns should be avoided

[karlcow]

This is happening in https://webcompat.com/issues/4313
When a user is typing a character in a form which is just after : without leaving a space. The converter will interpret it as an emoji. Some strings should be out of parsing because there are part of the system. Expected behavior: Should not be parsed for emojis.

[miketaylr]

😛

[zoepage]

@karlcow it might be enough to add a space after the :?
Could be a good quick fix before we redo the form.

(Disabling emoji rendering is tricky. Parsing the message maybe overhead?)

[miketaylr]

@karlcow it might be enough to add a space after the :?

That might work as a quick hack.

If we do move to a form with multiple textareas for expected/actual behavior (as has been suggested in a few issues), we can also avoid this problem by adding the expected/actual behavior headings to the user input ourselves, once they're submitted to the back-end.

But I agree we probably want some way to tell the emoji lib, don't look at these strings.

[zoepage]

This and #1171 and #613 could be probably fixed in one solution, when we parse the message and check for specific pointers?

[cch5ng]

hi, I'm starting to look at this bug. after #1547 gets merged, the text area placeholder will no longer contain ":". ie it has changed to:

For example,

1. I've tried to log in.
2. I've filled out the form details.
3. I clicked on the submit button.
4. Nothing happened.

does this mean this issue could be closed or should it still be fixed?

[karlcow]

Another instance in webcompat/web-bugs#19090
https://webcompat.com/issues/19090

GitHub has the same bug.