1208211 - html email is displayed differently than other renderers

Status: NEW

(Core :: Layout, defect)

Description

[Michael Wiktowy]

Attachment: Wonky Email Source - Scrubbed

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150827075926

Steps to reproduce:

Received an email that was possibly malformed.


Actual results:

Much of the plain text content was hidden while the partial (malformed) html content was displayed.


Expected results:

Other renderers of the same email (GMail web interface viewed through Chrome, Evolution, Email app on Android phone) all displayed the email as it was intended. Likely Firefox is making a very strict interpretation of syntax that the others are not. I am not sure if interpretation is wrong and you want to match the others or everyone else is wrong. I will attach the email source with source and recipient scrubbed but all else intact. If you want to original, unscrubbed email, please provide a side-channel to send it to.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

How did you view this email in Firefox? Was it through the gmail web interface or something else?

Comment 2

[Michael Wiktowy]

The viewing issue was seen via the full web interface of GMail at https://mail.google.com/ . It displayed the same way with Firefox mobile on my Android phone.

Switching to the dumbed down "html mode" of the web interface displayed the entire contents of the plain text portion of the email.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

FWIW the email you attached is multipart/alternative, and includes both a plain-text version and a HTML version of the email. Except that the HTML version only has the first sentence of the email and has a large number of useless div tags. So it sounds kind of like when you viewed this email in Firefox, Gmail decided to show the text/html version of the email and in other browsers/mail clients you got the text/plain version of the email.

Would you be able to take a screenshot of the email rendering in Gmail in Firefox vs Chrome?

Comment 4

[Michael Wiktowy]

I agree that is what is happening. I am wondering why every single other non-Firefox viewer is interpreting things "as intended" rather than strictly interpreting the garbage and displaying it.

I can certainly take a screen shot of what the exact same message looks like in Chrome, Firefox and Evolution ... but only later on today after I get home from work.

What I am noticing is that when I "Show original" in Chrome, I get more than the truncated version that I posted here ... I get a whole bunch more messy html including the content that was in the plain text portion.

I will post more details later.

Comment 5

[Michael Wiktowy]

Attachment: Wonky Email Source Scrubbed - fixed

Added a fix to scrubbed original email source. All the html info section was there. It was just after a large whitespace that I hadn't scrolled down for when I cut and pasted the first time.

Same rendering problem still exists ... just more mysterious why Firefox ignored everything after the whitespace ... differently for normal display and print layout display. See further attachments.

Comment 6

[Michael Wiktowy]

Attachment: Screenshot from Firefox.png

Comment 7

[Michael Wiktowy]

Attachment: Screenshot from Chrome.png

Comment 8

[Michael Wiktowy]

Attachment: Screenshot of Print Format from Firefox.png

Appears to also contain a rendering error of the GMail logo in the print format display. Firefox will not render the <img src="//www.gmail.com/mail/help/images/logo1.gif" width=143 height=59 alt="Gmail"> tag. Not sure why the http: or https: is missing but the same tag renders in Chrome.

Comment 9

[Michael Wiktowy]

Attachment: Screenshot of Print Format from Chrome.png

Comment 10

[Kartikaya Gupta (email:[e-mail])]

I can reproduce the issue by sending myself the attached email, and opening it in a gmail web interface. I inspected the HTML (by dumping the .innerHTML of the div containing the email body) and it does appear to have the full HTML, but as Michael observed, it is not visible in the interface. It appears to be a Firefox HTML parsing error, perhaps because of the depth of the nesting involved.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Sounds more like the HTML is all there, but we're hitting MAX_REFLOW_DEPTH or similar.