Replying or forwarding email with black background incorrectly applies background color.
Using Mailmate Version 1.9.6 (5371)
I received an email with a black background and proceeded to forward it. When I write a message in my reply above I can't see the text I am writing in the preview window because it seems Mailmate continues using the black background (possibly specified by the css in the email) in the new html it generates. It seems the issue affects all rendering of the "new" email in the app.
Here is a picture of what my preview window looks like while I'm creating my forwarded message. Pay attention to where the red arrow points. If you look closely the generated text I created above in markdown is black. But due to the dark/black background it is hard to read the text written. I believe the expected functionality is that the css brought in by the email should not apply from where the headers are printed in the email and up.
The same happens when replying to the email as well.
-
bennyThis is the tricky part of embedding HTML within HTML (which is not really supported by HTML).
Do you have “Inline CSS” enabled in the embedding method in the Composer preferences pane?
Can you forward an example message to me? (Use “Help ▸ Send Feedback” and then drag the email into the composer to attach it.)
-
Adonis
Attached are the options I have enabled. I have also sent you an example email. I went ahead and removed the premailer bundle to test as well and the same happens with the default scoped stylesheet.
-
benny
- State changed from new to fixcommitted
Thanks for the example. I was able to reproduce it and, at least in this case, fix it (when using Premailer). The problem was triggered by some conditionals in the HTML related to old versions of Internet Explorer.
It is, by the way, an example of horrible misuse of HTML in emails, but that is certainly not your fault :-)
-
Adonis
Thanks. Should I expect it to be fixed when not using Premailer as well?
-
Adonis
Not sure if this is fixed in build Version 1.9.6 (5374) but I issue still exists in this build.
-
benny
Sorry about the late response. You should not expect it be fixed when not using Premailer. Do you still have the issue with Premailer enabled? In that case, I'm going to need another example (unless you are still seeing the issue with the example you already sent me).
I'm not sure about the revision, but you can update to the latest to make sure we are on the same page: Hold down ⌥ when clicking “Check Now” in the Software Update preferences pane.
-
Adonis
Hi benny,
Why is this issue being fixed only when using premailer? Issue exists without premailer as well and I prefer not to use premailer as launching all html emails with premailer adds latency to opening the email message.
-
-
Adonis
As per my message back on July 5th above your last reply. Why is this not being fixed when not using Premailer? Opening messages with premailer enabled adds almost 1-2secs of time to open a message.
-
benny
- State changed from fixreleased to accepted
Sorry about the late reply. I simply don't have a good answer for you. In general, it really is best to use premailer to make sure that the HTML is cleaned up a bit. Otherwise, it's more likely that receiving email clients aren't going to display the emails correctly.
Rather than trying to work around the bad HTML when not using premailer I should probably look into running premailer on a separate thread to make the delay less of an annoyance. This might be harder to do, but it would be a more robust solution with regards to handling HTML in general.
The best I can offer for now is to put the ticket back into the “accepted” state waiting for asynchronous use of premailer to be implemented.
-
benny
- State changed from accepted to fixcommitted
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.