-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emoji rendering destroys paragraphs #6523
Comments
We apply the CSS class With Using
|
Same seems to happen for Braille Patterns (U+2800-U+28FF) possibly more. |
Will this see some fix/workaround in 0.14.x? Seems like a pretty annoying regression to drag along. |
I found the problem that caused this bug, will submit a pull request this evening. |
This regression was probably introduced in 4f4441f and is caused by the fact that the variable `isHtml` conflates two different meanings: - The event contains an HTML message - The event message is displayed using HTML This is an important difference. Plain text messages that contain emojies are rendered with an HTML string and thus have to be sanitized etc. But they must not use the MarkDown CSS styles for HTML messages. The MarkDown CSS styles include `whitespace: normal` because HTML events use `<br/>`-tags for line breaks. Plain text messages with emojies obviously don't use `<br/>`-tags, so these styles must not be applied.
This regression was probably introduced in 4f4441f and is caused by the fact that the variable `isHtml` conflates two different meanings: - The event contains an HTML message - The event message is displayed using HTML This is an important difference. Plain text messages that contain emojies are rendered with an HTML string and thus have to be sanitized etc. But they must not use the MarkDown CSS styles for HTML messages. The MarkDown CSS styles include `whitespace: normal` because HTML events use `<br/>`-tags for line breaks. Plain text messages with emojies obviously don't use `<br/>`-tags, so these styles must not be applied. Signed-off-by: Jonas Schürmann <schuermann@creios.net>
This regression was probably introduced in 4f4441f and is caused by the fact that the variable `isHtml` conflates two different meanings: - The event contains an HTML message - The event message is displayed using HTML This is an important difference. Plain text messages that contain emojies are rendered with an HTML string and thus have to be sanitized etc. But they must not use the MarkDown CSS styles for HTML messages. The MarkDown CSS styles include `whitespace: normal` because HTML events use `<br/>`-tags for line breaks. Plain text messages with emojies obviously don't use `<br/>`-tags, so these styles must not be applied. Signed-off-by: Jonas Schürmann <schuermann@creios.net>
This regression was probably introduced in 4f4441f and is caused by the fact that the variable `isHtml` conflates two different meanings: - The event contains an HTML message - The event message is displayed using HTML This is an important difference. Plain text messages that contain emojies are rendered with an HTML string and thus have to be sanitized etc. But they must not use the MarkDown CSS styles for HTML messages. The MarkDown CSS styles include `whitespace: normal` because HTML events use `<br/>`-tags for line breaks. Plain text messages with emojies obviously don't use `<br/>`-tags, so these styles must not be applied. Signed-off-by: Jonas Schürmann <schuermann@creios.net>
@zeratax The pull request also fixes the problem for braille characters |
@lukebarnard1 I removed the class |
Fix element-hq/element-web#6523 Emoji rendering destroys paragraphs
It does indeed, merged 😃 |
This seems to be a regression since
0.14.0
.The paragraphs in the following message get destroyed while rendering.
Original (as it appears in the message input box):
Resulting event:
Incorrectly renders as:
Workaround 1
Forcing Markdown-processing to trigger works around this problem.
The following message:
produces the following event, which renders correctly (paragraphs are preserved):
Workaround 2
If there's no emoji in the text, everything works well.
The following message:
produces the following event, which renders correctly (paragraphs are preserved):
The text was updated successfully, but these errors were encountered: