#1747 new

Replying or forwarding email with black background incorrectly applies background color.

Reported by Adonis | May 8th, 2017 @ 03:43 AM

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.

Comments and changes to this ticket

  • benny

    benny May 10th, 2017 @ 02:10 PM

    This 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

    Adonis May 10th, 2017 @ 02:40 PM

    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

    benny May 11th, 2017 @ 01:09 PM

    • 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

    Adonis May 11th, 2017 @ 01:27 PM

    Thanks. Should I expect it to be fixed when not using Premailer as well?

  • Adonis

    Adonis June 1st, 2017 @ 03:55 AM

    Not sure if this is fixed in build Version 1.9.6 (5374) but I issue still exists in this build.

  • benny

    benny June 9th, 2017 @ 02:59 PM

    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

    Adonis July 5th, 2017 @ 06:15 PM

    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.

  • benny

    benny September 22nd, 2017 @ 12:54 PM

    • State changed from “fixcommitted” to “fixreleased”
  • Adonis

    Adonis September 28th, 2017 @ 08:54 PM

    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

    benny October 2nd, 2017 @ 12:19 PM

    • 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

    benny November 1st, 2021 @ 09:48 AM

    • 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.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

People watching this ticket