Skip to content
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

Unexpected, unredable characters in generated HTML #1667

Open
UNOwen opened this issue Sep 9, 2024 · 18 comments
Open

Unexpected, unredable characters in generated HTML #1667

UNOwen opened this issue Sep 9, 2024 · 18 comments

Comments

@UNOwen
Copy link

UNOwen commented Sep 9, 2024

Describe the Bug

When rendering HTML using react-email 3.0.1, I randomly observe unprintable characters rendered in between or instead of the non-latin letters of the email text, no more than 1-2 occurrences per email typically. The issue seems semi-random, dependent on the amount of react markup and text before the affected character, and also dependent on the execution environment (locally rendered preview and server-side cloudflare worker insert these "broken" characters at different parts of the rendered HTML).

Example:

<Text className="text-zinc-600 dark:text-zinc-300 leading-6">
        Поздравляю! Вы завершили офлайн-курс по улучшению речи и литературному мастерству Litcondit. 
        Если вам понравились занятия и вы заинтересованы в том, чтобы научиться виртуозно говорить и писать, 
        а еще разбираться в литературе, приходите на занятия:
</Text>

Result:

Поздравляю! Вы завершили офлайн-курс по улучшению речи и литерату�рному мастерству Litcondit. 
Если вам понравились занятия и вы заинтересованы в том, чтобы научиться виртуозно говорить и писать, 
а еще разбираться в литературе, приходите на занятия:

(note the character)

        "@react-email/components": "^0.0.24",
        "@react-email/preview": "0.0.11",
        "react-email": "3.0.1",

Which package is affected (leave empty if unsure)

react-email

Link to the code that reproduces this issue

https://github.com/UNOwen/litcondit-worker

To Reproduce

Have the below snippet repeated multiple times:

<Text className="text-zinc-600 dark:text-zinc-300 leading-6">
        Поздравляю! Вы завершили офлайн-курс по улучшению речи и литературному мастерству Litcondit. 
        Если вам понравились занятия и вы заинтересованы в том, чтобы научиться виртуозно говорить и писать, 
        а еще разбираться в литературе, приходите на занятия:
</Text>

Preview the dev version of emails or render in production. Observe broke characters in the email.

Expected Behavior

No unprintable characters in the email.

What's your node version? (if relevant)

No response

@UNOwen UNOwen added the Type: Bug Confirmed bug label Sep 9, 2024
@blnvdanil
Copy link

We have also encountered this bug, it occures randomly, any change to the JSX layout or styles may lead to appearing/disappearing of these characters, it seems to be a \0 character

@gabrielmfern
Copy link
Collaborator

The code to the reproduction seems to be down, can you make it public?

@UNOwen
Copy link
Author

UNOwen commented Sep 13, 2024

The code to the reproduction seems to be down, can you make it public?

Gabriel, I’d like to keep the repository private, but I granted you access.

@UNOwen
Copy link
Author

UNOwen commented Sep 14, 2024

Upon some basic investigation, the character involved has hex byes of EF BF BD, and is the https://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?input=%EF%BF%BD&mode=char "REPLACEMENT CHARACTER". It repeats twice in a row a lot of the time. It overwrites the contents of the email rather than inserting itself in between letters. E.g. hex bytes D0 BF for letter "п" were replaced with EF BF BD EF BF BD. The bytes replaced seem random. The replacing characters are always the same replacement character as far as I could reproduce.

@KevinGregull
Copy link

We see the same issue occuring. For us it happens on the "€" Character. I am quite certain that this is not an input encoding problem but rather something that occurs during the rendering of the HTML. Because we do display the € sign in Order Line-Items which are rendered in a loop. Sometimes a single of the looped € Characters is being replaced by the aformentioned �� characters, while the others render fine. It also happens with Umlauts sometimes "äöü". I've never seen it occur in any standard ASCII Character, thus far.

@gabrielmfern
Copy link
Collaborator

@KevinGregull @UNOwen What other things about the environment you are using to render can you share (OS, rendering in the browser, in Node, what browser)?

@UNOwen
Copy link
Author

UNOwen commented Sep 26, 2024

The issue seems to be universal. I am observing these characters appearing both when rending emails within Cloudflare workers, and while on my macOS desktop in preview mode in the browser.

@gabrielmfern
Copy link
Collaborator

Asking this because I'm really not getting any null characters on my side, and I'm running things on Linux with the same email template. It might be something related to Mac in general because the preview server does not call render in the browser

@blnvdanil
Copy link

blnvdanil commented Sep 26, 2024

In my case, I run it on Arch Linux and have the same problem

@gabrielmfern
Copy link
Collaborator

Got a reproduction of it, but not in the preview server — only when rendering directly with JavaScript in the browser.

@KevinGregull
Copy link

I am rendering it as a cli application. It's running in the bun docker Container oven/bun.

@gabrielmfern
Copy link
Collaborator

Released a fix that worked on my reproduction. Could you all test with @react-email/[email protected] or @react-email/[email protected]?

@UNOwen
Copy link
Author

UNOwen commented Sep 27, 2024

With these component versions installed, the email appears to be completely blank when rendered on a cloudflare worker and displayed in Firefox browser or email client like Mail. The HTML seems to be in place, but there is some javascript which gets appended and removing the content upon render, and there's a "hidden" attribute on the HTML content. The HTML seems to not have the reported unexpected characters. Text version of the email is not affected, as in it displays well and without unexpected characters.

demo.html.zip

@gabrielmfern
Copy link
Collaborator

@UNOwen Tried with the same email template as the one you sent, and it worked just fine, none of the details you mentioned. The latter script seems to me like a hydration script — you might have called the wrong render to test this out, maybe you called the react-dom one?

@UNOwen
Copy link
Author

UNOwen commented Sep 27, 2024

I am using "react-email": "3.0.1" to set rendering up overall, and using import { render } from '@react-email/components' method. Rendering worked before updating the dependencies, and I haven't done any changes outside of updating the two dependencies you mentioned. The repository is linked in the bugreport.

@UNOwen
Copy link
Author

UNOwen commented Sep 28, 2024

Upon upgrading react-email to 3.0.2-canary.2 on the whole, I am still observing "empty" HTML emails upon delivering to the email inbox. Browser preview in the dev server looks fine.

@grigmag
Copy link

grigmag commented Oct 30, 2024

Hi, I'm also experiencing the same problem using the greek language, even in the 3.0.2-canary.2 version.

See my minimal reproduction here (make sure you are in the correct branch, which is not the main branch):
https://github.com/grigmag/react-email-unreadable-characters-bug/tree/unreadable-characters-bug

The produced output in the dev server (pnpm dev) after a large amount of repetions of the text "Αβγδεζηθικλμνξοπρστυφχψω" becomes "Αβγδεζηθικλμνξοπρστυφ�χψω".

When sending the test email, I do not see the character in my gmail, so the bug does not seem to affect the sent emails for me.

Edit: Forgot to add that the character might not appear initially after opening the email in the dev server, but it appears after refreshing the page.
Edit 2: Also tried installing the 0.0.26-canary.3 version of @react-email/components, and I am still experiencing the problem.

@gabrielmfern
Copy link
Collaborator

@grigmag Thanks for sharing, was able to reproduce, will see into fixing it. But it seems to me as another issue causing this in your case, the problem reported by others here should already be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants