834734 - [EMAIL] HTML message display in newsletter mode may result in extremely wide iframes with bad aspect ratio for some messages

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[ayman maat :maat]

Attachment: example of unconsumable email.

Email displays content as is, and does not optimise for our devise - This results in unreadable / unusable emails.

refer to attachment. The lines below the subject are actually the content of the email.

[TEF_REQ] as Feature required for TEF build.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Wow, that does look pretty hard to read!

This looks like a mail message that is triggering our 'newsletter' display mode.  I would guess that this is an HTML e-mail that has some styling directives or un-broken text that makes us think the e-mail intentionally wants to be super-wide.  We oblige it because we think it knows what it is doing, and set the width to be as requested, then zoom things way out and enable our pinch-to-zoom/double-click logic.  The zooming affordance probably doesn't work because the message is vertically so small.

If you could forward me a copy of the message at [e-mail] from a mail client other than the gaia e-mail app, such as your webmail interface or Outlook or Thunderbird, etc. that would let me see the HTML source to the e-mail and better understand what's happening.  Forwarding the message as an attachment is the most accurate way to relay the message, but an inline forwarding might also be okay.  Thunderbird, for one, has a "Forward As" option in its menuing system.

Probably the right course of action for us would be to cap the maximum width we would assign in newsletter mode to something more on the order of 600px-1000px.  We might be able to add an additional heuristic to detect cases like this one and disable newsletter mode.

Comment 2

[ayman maat :maat]

> If you could forward me a copy of the message at [e-mail]
> from a mail client other than the gaia e-mail app, such as your webmail
> interface or Outlook or Thunderbird, etc. that would let me see the HTML
> source to the e-mail and better understand what's happening.  Forwarding the
> message as an attachment is the most accurate way to relay the message, but
> an inline forwarding might also be okay.  Thunderbird, for one, has a
> "Forward As" option in its menuing system.

Hey Andrew, the screenshot was not generated by me, it was generated by Rafa whilst we were discussing the presentation of email content in the email app. I just raised the bug and attached the screenshot. So RFI to Rafa to provide Andrew with the information he requires in order to address this.

Comment 3

[Rafael Rebolleda]

Andrew,

I'll fwd the msg to you through gmail. Let me know if that works.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

I received the forwarded mail.  The mail has a text/plain component (which we don't use) and a text/html component, both are quoted-printable.

The e-mail primarily consists of legal disclaimer.  In the text/html part, this is wrapped in a set of <pre> tags and has quoted-printable encoded soft-line breaks that make the lines reaaalllly long.  The text/plain part does not share the too-long lines, probably because wrapping logic was called into effect.

Thunderbird displays the message along the same lines we do; the too-long lines cause a scroll region to be setup that is very wide.

While the boilerplate template is arguably very incorrect, such is the bleak and horrible reality we inhabit.  I propose my previous suggestion about capping the maximum width of our iframe in conjunction with adding a style equivalent to: "pre { white-space: pre-wrap; }" that can be overridden, but should otherwise make situations like this much less horrible.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/8036

The 'pre' rule fixes the problem.  The html/body rules are speculative fixes without much justification.  Mainly, the idea is that it's better to apply that constraint in the CSS rather than trying to do it after the fact by having the JS set an explicit width rule and then trigger another re-flow.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

landed on gaia/master:
https://github.com/mozilla-b2g/gaia/pull/8036

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 712347 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/8036

[Approval Request Comment]
This is marked TEF UX critical.  This is nicely standalone CSS stuff that's localized and orthogonal to all other CSS because it's for an iframe that has no other gaia css in it.

Comment 8

[John Ford [:jhford] CET/CEST Berlin Time]

v1-train: 21c8112e6b0d023a7c6fe67be1f6409070e613cf

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: bugs fixed on b2g18 since 1/25 branch of v1.0 are fixed on v1.0.1