1659362 - message content rendered with significantly reduced width for same message in Thunderbird 78 vs. 68

Status: ASSIGNED

(Thunderbird :: Message Reader UI, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: screenshot comparing message's width in Thunderbird 81 with 68

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.

Comment 1

[Magnus Melin [:mkmelin]]

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

Comment 2

[Jorg K (CEST = GMT+2)]

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.

Comment 3

[Magnus Melin [:mkmelin]]

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

Comment 4

[Wayne Mery (:wsmwk)]

(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?

Comment 5

[Magnus Melin [:mkmelin]]

Attachment: bug1659362_conditional_css_false.patch

Let's make this off by default for now.

I think it should go on 78.

Comment 6

[Kai Engert (:KaiE:)]

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.

Comment 7

[Kai Engert (:KaiE:)]

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

Comment 8

[Magnus Melin [:mkmelin]]

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

Comment 9

[Kai Engert (:KaiE:)]

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

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

Comment 10

[Magnus Melin [:mkmelin]]

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

Comment 11

[Kai Engert (:KaiE:)]

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.

Comment 16

[Magnus Melin [:mkmelin]]

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

Comment 18

[Petr Hroudný]

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

Comment 19

[Petr Hroudný]

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;}

Comment 20

[Kai Engert (:KaiE:)]

(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?

Comment 22

[Kai Engert (:KaiE:)]

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.

Comment 23

[IT Support]

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?

Comment 27

[Todd M. Lewis]

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

Comment 28

[Magnus Melin [:mkmelin]]

Yes. That was meant for bug 1669274.

Comment 29

[Magnus Melin [:mkmelin]]

Bug 1688659 provides further input the pref is rather futile.

Comment 30

[Avner Falk]

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.

Comment 31

[Louis Lazaris]

Attachment: newsletter-example-that-breaks.eml

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.

Comment 32

[jarroyo1982]

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

Comment 33

[badertscher]

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

Comment 34

[Kai Engert (:KaiE:)]

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.

Comment 35

[IT Support]

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?

Comment 36

[Magnus Melin [:mkmelin]]

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.

Comment 37

[Magnus Melin [:mkmelin]]

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

Comment 38

[Remi]

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

Comment 39

[Wayne Mery (:wsmwk)]

(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?

Comment 40

[Rachel Martin]

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

Comment 41

[Kai Engert (:KaiE:)]

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