1442577 - Body of some emails in Gmail not shown when view with Firefox.

Status: RESOLVED DUPLICATE of bug 256180

(Core :: Layout, defect)

Description

[loy heng]

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

I had received certain emails from one sender. 


Actual results:

When I opened the email, the body of the email was not shown (blank). Only top line "Dear Sir" appeared. I reloaded numerous times but still the same. I had the sender resent the same emails even using Gmail but to no avail. But when I viewed my Gmails in Internet Explorer 11 or Google Chrome, the full email was shown (text and images).


Expected results:

Capable to view the specific emails in full as other competing browsers. I don't know why Firefox gave so much problems as compare to even Google Chrome, a newbie in the browser space. Is there a reasonable excuse? If not because of the superior font color rendering in Firefox compare to Chrome I would have already switch.

Comment 1

[David Olah]

Hi loy heng,

I tried to reproduce the issue on Firefox 58.0.2 and on Nightly 60.0a1 (2018-03-06)(Windows 10.0, x64) but the whole content of the mail appears. It is my assumption that the mail that you received contains something that firefox cannot render correctly.

In order to reproduce and fix the problem, could you please send us the content of the mail that created you this issue or if you have confidential data in it, an example of a mail that has the same kind of content?

Comment 2

[loy heng]

Attachment: Email print view as shown in Firefox

Comment 3

[loy heng]

Attachment: Email print view as shown in Google Chrome Page 01

Comment 4

[loy heng]

Attachment: Email print view as shown in Google Chrome Page 02

Comment 5

[loy heng]

Hi David,

Thank you for looking into this issue. I had appended images of the email as viewed through Firefox (in safe mode) and Google Chrome browser (same as viewed in Internet Explorer 11). Thank you.

Comment 6

[David Olah]

Looking into loy heng's attachment I concluded that there is definitely something wrong. That might work investigating it.

Comment 7

[Daniel Holbert [:dholbert]]

Agreed, something looks wrong here.  Thanks for reporting the issue, Loy!

Unfortunately, I haven't been able to reproduce the issue yet.  I tried to reproduce by creating an email like the one shown (with images inline, and separately with images as attachments), sending the email to myself, and opening it in Print View -- but I couldn't trigger any sort of clipping.  So I'm guessing there's some special factor in the email in question here that I'm missing (or perhaps a special factor in Loy's configuration).  But I can't be sure what that special factor is.

Loy: if you're comfortable forwarding the email to me ([e-mail]), I'd be happy to take a closer look, and I'll keep the email itself confidential.  (It looks like it might contain a username/password for a download page of some sort -- if that username/password is sensitive, i.e. gives access to your account data or something, you probably want to delete that from the email before you forward it.)

Alternately: if you'd be more comfortable and feel up for a bit of tinkering, perhaps you'd be up for trying to create modified/reduced versions of the same email on your own (by forwarding it to yourself and editing the forwarded copy to remove sensitive information & more), and seeing whether they still trigger the problem -- and then I'd encourage you to forward one of those edited emails along to me, also/instead.

Comment 8

[loy heng]

Thanks Daniel for your attention.

I had forwarded the specific email to your email inbox twice, once from using Firefox and then using Google Chrome. Those sensitive information has not been deleted but I have changed the access password. No worries, thanks.

From my own experiment from sending the email to my another email address. The following results obtained.

If sent from Firefox and read in Firefox, the message was trimmed and only the opening line "Dear Sir" was visible.
If sent from Firefox and read in Google Chrome, the same message was jumbled up in one heap without any images in the middle.
If sent from Google Chrome and read in Firefox, the message was trimmed and only the opening line "Dear Sir" was visible.
If sent from Google Chrome and read in Google Chrome, the message was shown in full with images in the middle. i.e. everything seemed normal.

I don't think this got to do with my configuration as I tested them in Firefox safe mode and there was no problem in both Google Chrome and Internet Explorer 11 as all reside in the same desktop.

Thank you.

Comment 9

[Daniel Holbert [:dholbert]]

Thanks very much for forwarding that!

So part of the issue here is that the email is HTML formatted, and its formatting is a bit insane. :)

Specifically: it wraps most of the content in two <table> elements and ~190 layers of wrapper <div> elements, for no apparent reason.  (I'm guessing this was from a WYSIWYG editor having gone crazy -- maybe from someone e.g. reapplying a font customization in their editor over and over, and the editor dutifully adding a new wrapper-div each time).

The wrappers in the email look like this:
> <div style="FONT-SIZE:small;FONT-FAMILY:&#39;Calibri&#39;;FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;TEXT-DECORATION:none;DISPLAY:inline">
> <div style="FONT-SIZE:small;FONT-FAMILY:&#39;Calibri&#39;;FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;TEXT-DECORATION:none;DISPLAY:inline">
> <div style="FONT-SIZE:small;FONT-FAMILY:&#39;Calibri&#39;;FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;TEXT-DECORATION:none;DISPLAY:inline">
> <div style="FONT-SIZE:small;FONT-FAMILY:&#39;Calibri&#39;;FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;TEXT-DECORATION:none;DISPLAY:inline">
> <div style="FONT-SIZE:small;FONT-FAMILY:&#39;Calibri&#39;;FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;TEXT-DECORATION:none;DISPLAY:inline">
> [...etc, going on for quite a while]

I suspect that the testcase is simply hitting Firefox's internal limit for "too many layers of nested elements" -- at least, if I delete some of the last few <div> wrappers, then everything starts rendering fine.   But it's something more subtle than that, too -- it seems like the 2 table-wrappers are considerably lowering the threshold at which we bail out and stop rendering things, for some reason.

I'll attach some testcases to demonstrate.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (2 tables + 190 wrapper divs) - inner text completely missing in Firefox 60, fine in Chrome

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (2 tables + 187 wrapper divs) - passes in Firefox 60 & Chrome

This testcase is just like the first one, but with 3 fewer wrapper divs, and that's enough to make it pass in Firefox.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (200 wrapper divs) - text visible but unstyled in Firefox

This testcase is like the first one, but I've removed the two tables and instead added 10 more wrapper divs (to keep the number of wrapper boxes approximately the same -- adding 5 for each table that I removed. Each table spawned ~5 wrappers, for tableouter/tableinner/row/cell/cell-container-block).

With this change, the text shows up, but it's unstyled in Firefox (styled correctly in Chrome).  The styling shows up if I remove a few layers of wrapper divs, so we're still going over some nesting threshold.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 - (1200 wrapper divs) - text visible but unstyled in Firefox (just as in testcase 3)

Here's a testcase with way more (1200!) wrapper divs.  This renders just like testcase 3 - the text is visible but unstyled.

So there's something about the presence of the table wrappers here that messes us up, whereas we're closer to fine (but not 100% fine) with arbitrarily many block (<div>) wrappers.

Comment 14

[Daniel Holbert [:dholbert]]

Chrome and Edge both render testcases 1, 2, and 3 just fine (with the inner text visible & correctly styled).

Chrome renders testcase 4 fine as well. Edge does not - it gives me an error page ("This page is having a problem loading.")  So they've got a nesting limit as well, and it's somewhere between 200 and 1200. :)

(Firefox is arguably nicer than Edge on testcase 4, in that we simply fail at styling the inner text, though we do render it.)

Comment 15

[Daniel Holbert [:dholbert]]

Looks like this Firefox behavior is intentional, basically.

We have the max layout depth defined at exactly 200 boxes (which may not be precisely 200 HTML elements, since some elements like e.g. <body> get an extra box or two):
> #define MAX_REFLOW_DEPTH 200
https://dxr.mozilla.org/mozilla-central/rev/a6a32fb286fa9e5d5f6d5b3b77423ab6b96c9502/layout/generic/nsIFrame.h#16
If we surpass that depth, it makes us set a bit on the deepest-nested boxes to stop rendering them, and that's documentated here:

> // If this bit is set then the frame is too deep in the frame tree, and
> // we'll stop updating it and its children, to prevent stack overflow
> // and the like.
> FRAME_STATE_BIT(Generic, 11, NS_FRAME_TOO_DEEP_IN_FRAME_TREE)
https://dxr.mozilla.org/mozilla-central/rev/a6a32fb286fa9e5d5f6d5b3b77423ab6b96c9502/layout/generic/nsFrameStateBits.h#111-114

(I'm not immediately sure why we manage to render the unstyled text in testcases 3 and 4... *shrug* maybe we just skip over a lot of the nesting wrapper-boxes in some of the codepaths that get triggered by this fallback handling, or something.)

Also worth noting: this behavior hasn't changed for quite a while.  We fail on testcase 1 in the same way all the way back at least as far back as pre-"Firefox 4" builds (the oldest builds that run on my machine, I think).  I tested a Firefox Nightly from 2010-04-03, and it fails to render the second line of text in testcase 1, just like current Firefox does.

Bottom line: this is Firefox basically trying to detect pathological content, and opting to skip rendering parts of that content, rather than letting that content make us run out of stack space and crash.  Programs can only have so many nested function-calls before they run out of stack-space and crash, and Firefox is erring on the side of being conservative right now. Maybe 200 is too low and we could safely increase that threshold, but there will always be *some* threshold (probably within an order of magnitude of 200) that we have to set for ourselves where we bail out to avoid crashing.

This content is just unlucky enough to be *just* over that threshold (with tons of extra/unnecessary wrappers).

Comment 16

[Masatoshi Kimura [:emk]]

Dup of bug 256180?

Comment 17

[Daniel Holbert [:dholbert]]

I think so! thanks.