Thunderbird 78.1.1 on Windows 8.1

The content of the same message (I get similar messages frequently and it applies to all of these GMX spam reports) gets rendered with a much smaller width (300 pixels) in Thunderbird 78 (also with 81) vs Thunderbird 68 (rendered with 620 pixels width).

Is this a regression or a fix (in the email body, there is a table with width "300" mentioned)? If you need such an email, let me know.

Yes please attach a sample .eml.
Can't say from the screenshot, but is it due to remote content blocking in 81 but not in 68? (For whatever reason, they should be the same.)

I think it's due to removing conditional CSS in bug 1530106. That bug removed so-called media queries. That destroys the display of some messages, see bug 1530106 comment #60. I bet you'll find the media query in the HTML of your e-mail as it looks like the e-mail is now rendered for a small device. Luckily there is a pref you can set to disable the new "security feature": mail.html_sanitize.drop_conditional_css.

It might be best to default mail.html_sanitize.drop_conditional_css to false for now, especially as the fix is not really complete.

(In reply to Magnus Melin [:mkmelin] from comment #3)

It might be best to default mail.html_sanitize.drop_conditional_css to false for now, especially as the fix is not really complete.

Do you want that for 78.2.0?

Let's make this off by default for now.

I think it should go on 78.

This suggestion makes me sad. It was a lot of work to get a fix for bug 1530106 in place.
IMHO, if it's incomplete, we should try to make it better, not remove it.

I think the subject wants to say "reduced width" (not "reduced risk")

(In reply to Kai Engert (:KaiE:) from comment #6)

IMHO, if it's incomplete, we should try to make it better, not remove it.

Sure, but: lack of time, and iterating on a solution would still not be suitable for esr + the feedback cycles the iterations should have. So we now have the situation that it's ultimately not fixing bug 1530106 but still causing slight adverse effects. Effects we could perhaps put up with if the fix was complete. As it stands there's basically no gain from it.

The gain is that "simple" scenarios to trick the user don't work.

It takes more complicated more approaches to trick the user, IIUC.

Bug 1530106 comment 94 and 95 are about as simple as it gets though :/

Maybe it's a silly comparison, but car makers have improved the use of airbags over the years, fixing one more risk scenario after the other. Nobody said "there's still a risk to get injured if the other car hits us in a 63° angle, so let's stop using airbags altogether".
I think we shouldn't increase the risk to get hurt, just because we haven't fixed all angles yet.

The issue reported in this bug here isn't serious. It's just a different rendering, but the message contents are visible.

Also caused bug 1675507 (probably bug in parserutils, but this exposes it)

(In reply to Kai Engert (:KaiE:) from comment #6)

This suggestion makes me sad. It was a lot of work to get a fix for bug 1530106 in place.
IMHO, if it's incomplete, we should try to make it better, not remove it.

Kai, could you please prepare a simple one-line fix, which properly closes the comment in <style> section?

The problem described in bug 1675507 is much more severe, users can't see important parts of forwared or original message in several MUAs due to incorrect commenting of <style> section. Properly inserting the end of comment (-->) should be trivial.

I've looked closely to attached email examples in bug 1675507. What happens is this:

Outlook inserts <style> section into emails, but the whole section is not used - it's commented out:
<style><!-- .... --></style>

Sanitizer keeps start of comment <!-- but removes end of comment -->
so now the comment extends beyond </style> tag and the rest of message is not displayed.

Instead, it should completely ignore commented sections.

Except this, it malforms several items, e.g.

Before sanitizing:

.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}

After sanitizing:

.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}

(In reply to Petr Hroudný from comment #18)

Kai, could you please prepare a simple one-line fix, which properly closes the comment in <style> section?

What makes you believe the fix is as simple as that?

Regarding the action we should take for Thunderbird 78.x, I've started a discussion on the Thunderbird planning mailing list:
https://mail.mozilla.org/pipermail/tb-planning/2020-December/thread.html

As mentioned in that post, for future versions, maybe we shouldn't silently decide, maybe it's better to involve the user.
I've filed bug 1680499 to track that idea.

Why don't you flip the preference for now given the many duplicates you're collecting here? According to bug 1530106 comment #95 the fix in that bug was (quote) "very incomplete" spawning off bug 1603299. It's not likely that bug 1680499 will deliver any immediate solution. Magnus who proposed that change seems to be the module owner, so he's just overruled? What is the decision-making process in case of an incomplete solution (bug 1530106) with unwanted side-effects (this bug here and duplicates)?

maybe we shouldn't silently decide

Well, you silently decided to not honour certain CSS any more. Was there any user consultation on that? Why does it need user consultation now to just go back to the previous accepted status of decades and then embark on a complete and non-obstructive solution?

Perhaps a typo? I don't see how bug #1688848 is even related to this bug, much less a duplicate.

Yes. That was meant for bug 1669274.

Bug 1688659 provides further input the pref is rather futile.

I totally agree with Todd. Bug 1688848 is different and separate from this bug. Bug 1669274 may be a duplicate, but it has not been resolved.

This is one example of my newsletter where this feature breaks the layout. The top few rows should appear in two-column mode, but they don't do that when the media queries are disabled.

It's curious when you COMPOSE an HTML email by pasting code, media queries are followed. That's OK: As you shrink or enlarge the compose window, the responsiveness of the layout is applied. The problem appears when you SEND the message. The stored message in the "Sent" folder ignores the media queries.

This is still happening Thunderbird release (78.7.0).

May I ask you to provide an update on this bug? Any estimate when this should be solved in newer version of Thunderbird?

I had started a discussion here:
https://mail.mozilla.org/pipermail/tb-planning/2020-December/008048.html

Because of lack of time, I unfortunately haven't yet been able to follow up to that discussion.
But my impression is, a majority seems to prefer to rather stay on the safe side - which would mean to wontfix this bug.

Please refer to our comment #23. We haven't counted the affirmative replies on the tb-planning thread, but you have eight duplicates here and there are users asking on SUMO. Neither bug 1603299 has been actioned (or maybe it has, it's access restricted) nor bug 1680499. So how can doing nothing improve the situation?

It's a complex topic, and I don't think any of the responders from tb-planning even understood what they were asked. Even if they would, you're going to get a certain bias...

So I don't know, from that discussion there wasn't really much valuable input and no new ideas how to fix it.

Bug 1680499 is probably a good way to solve it for real, but may not be the easiest to do.

For 78, I still think we should back out until there's a real solution. As it, it's a pointless degradation of content.

Being familiar with a lot of email client and this sort of issues, I would love to help guide you on a right track. But I'm not sure how to and where to do this. Should I create a new issue to discuss this? (I don't think the aforementioned issue is a proper solution for this either.)

(In reply to Magnus Melin [:mkmelin] from comment #37)

For 78, I still think we should back out until there's a real solution. As it, it's a pointless degradation of content.

Who will be doing the backout?

Can you finally move this forward together with bug 1680499 and bug 1603299.

(In reply to Wayne Mery (:wsmwk) from comment #39)

Who will be doing the backout?

I think it was the right decision not to back out.
The current behavior is the more secure behavior, and someone will have to find time to work on a better solution, as already suggested in the referenced bugs.