1722671 - Gmail tab hangs when opening a specific email with tons of emoji that get loaded as images via innerHTML

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Sameer]

Attachment: firefoxdos.mkv

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Hi,
Firefox Team, I found that when i send a very large email with special characters , and whenever a receiver opens it , It hangs the tab, User are not able to do anything not even refresh.

1. Send an email with payload. i am using gmail as email service.
2. Open that email at receiver end with latest fire-fox browser.
3. The tab will stuck, and you are not able to perform any actions in page.
4. You can modify the payload for critical impact and , repeat the payload more then one time.

Attaching payload and a video to show impact.

Thanks.

Actual results:

While, opening a mail it hangs the tab and users are not able to proceed further.

Expected results:

While, opening an email it should, load email perfactly without hanging the tab, and user should do their work flawlessly. As i checked in chrome and edge , The same email is working flawlessly.

Comment 1

[Sameer]

Hello,

              i noticed that on android os, the latest version of firefox application handles it correctly, but in Fire-Fox lite , It hangs the tab like described above, So Firefox Lite Apk is also effected by this. For checking in Firefox lite send the email and Open it at receiver end open it in firefox lite , and expand the email it will stuck the tab, or sometime it loads after few minutes , but what is the use, if you open a mail and , you can see that mail after few minutes !

Thanks.

Comment 2

[:Gijs (he/him)]

Can you attach an eml or similar file that contains the email in question?

Alternatively, have you tried using the profiler to see why the tab is hanging?

As it is, this report does not contain enough information to either reproduce the issue or determine what the issue is (and if it is even an issue with Firefox, rather than with gmail - gmail which will be using different code in Firefox than in Chrome, so the fact that it works in other browsers isn't really a guarantee of anything.)

Comment 3

[Sameer]

Hi,
No I haven't used Firefox profiler, here the issue is opening an email hangs the tab, for reproduction
I can send u an email, can u provide any demo email so ,I can sand that email? Or should i send it here?
And I think the issue is in Firefox ,not in gmail !

Thanks.

Comment 4

[:Gijs (he/him)]

(In reply to Sameer from comment #3)

I can send u an email, can u provide any demo email so ,I can sand that email? Or should i send it here?

In gmail, you can select the email using the checkboxes, then use the vertical dot menu at the top to "forward as attachment", then you can click the link to the eml file that gmail attaches to your new message, and download it. Then you can attach that to this bug here: https://bugzilla.mozilla.org/attachment.cgi?bugid=1722671&action=enter

Comment 5

[Sameer]

Hi,
Thanks for this much help i am attaching it ,But Sender will not get affected by this, Only those who receive's the email and opens it, Only those are affected.

Comment 6

[Sameer]

Attachment: aa.eml

Here is elm file. Thanks.

Comment 7

[:Gijs (he/him)]

hm, well, gmail does something dumb when trying to display this message in Firefox, it repeatedly sets innerHTML in a way that loads the emoji image for https://fonts.gstatic.com/s/e/notoemoji/13.1.1/2665/72.png multiple times. It also appears to be using an intersectionobserver in a way that we don't really like. Profile (but censored because otherwise it'd have my work gmail stuff): https://share.firefox.dev/3rMUrrd

For me, the email does eventually load, but it's slow and janky and I see tab spinners.

This should be fairly easy to repro. What I'm less clear on is why this janks so badly in Firefox and not (per the reporter; I haven't tried) in Chrome, but if I had to guess, it'd be that gmail-in-chrome ends up relying on the rendering engine to render all the emojis using a font available on the system, and gmail-in-firefox decides to replace the emojis with "manual" images, which is super janky because there are like a million of them. I don't know why gmail does that, but I suspect that if you did the same thing in Chrome, it too would not like it. Jonathan or Emilio, are you perhaps in a position to confirm this suspected cause, and/or check if there's something obvious our DOM/layout code could do better here? Or is there something we can reach out to google about to fix in gmail, so it doesn't take this path in Firefox?

Comment 8

[Sameer]

Hi,
Hello, there, can you tell me how you determined this , just want to know! And now what should I do? Should I report to google
Or you will manage everything?

Thanks.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs (he/him) from comment #7)

hm, well, gmail does something dumb when trying to display this message in Firefox, it repeatedly sets innerHTML in a way that loads the emoji image for https://fonts.gstatic.com/s/e/notoemoji/13.1.1/2665/72.png multiple times. It also appears to be using an intersectionobserver in a way that we don't really like. Profile (but censored because otherwise it'd have my work gmail stuff): https://share.firefox.dev/3rMUrrd

For me, the email does eventually load, but it's slow and janky and I see tab spinners.

This should be fairly easy to repro. What I'm less clear on is why this janks so badly in Firefox and not (per the reporter; I haven't tried) in Chrome, but if I had to guess, it'd be that gmail-in-chrome ends up relying on the rendering engine to render all the emojis using a font available on the system, and gmail-in-firefox decides to replace the emojis with "manual" images

I tried opening this email in gmail on chrome, and it does the same image-replacement thing there, loading the notoemoji/13.1.1/2665/72.png image in place of the heart characters. It's a bit slow to load for me in chrome too, but not as badly as in firefox.

(Aside: I think this is a somewhat strange thing for gmail to decide to do in this case, given that U+2665 does not have the Emoji_Presentation property, so the default Unicode expectation would be for it to render as a plain text glyph unless the U+FE0F variation selector is used to explicitly request emoji-style presentation. Still, even if they didn't do it for this symbol character, it looks like they substitute their .png images for all emoji when viewing an email, so the issue would be reproducible with "real" emoji characters as well.)

Comment 10

[Jens Stutte [:jstutte]]

I had a short look at the profile and there seem to be two phases during that load that split around 8,5 secs. First the layout engine is very, very busy with various things and then DOM/network is busy with set Element.innerHTML. The majority of load in the second half seem to be mainly array operations. Assuming that the number of elements in some array rises only linear with the number of emojis and thus should not be too high for a modern computer: Might we see some quadratic behavior of nsTArray functions here? Unfortunately the profile depth ends at some point, probably due to the inlining of templates.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

The profile I took locally looked fairly different. Bug 1722968 should help a lot, and I want to re-profile once that lands.

Comment 12

[Daniel Veditz [:dveditz]]

If this is simply DOS-ing the GMail tab/process (and from the description above, arguably at least partly GMail's own doing) it's not really a security vulnerability is it? Is it hanging the parent process, too?

Comment 13

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #12)

If this is simply DOS-ing the GMail tab/process (and from the description above, arguably at least partly GMail's own doing) it's not really a security vulnerability is it? Is it hanging the parent process, too?

I don't think so, I think this can be opened up if that works for you.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Attachment: Reduced test-case.

So the IntersectionObserver really is the lazyload observer we use for loading="lazy"...

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Attachment: Another one for easier scrolling.

Comment 16

[Sameer]

(In reply to :Gijs (he/him) from comment #4)

(In reply to Sameer from comment #3)

I can send u an email, can u provide any demo email so ,I can sand that email? Or should i send it here?

In gmail, you can select the email using the checkboxes, then use the vertical dot menu at the top to "forward as attachment", then you can click the link to the eml file that gmail attaches to your new message, and download it. Then you can attach that to this bug here: https://bugzilla.mozilla.org/attachment.cgi?bugid=1722671&action=enter

Hello,
Hope your doing well, So can you tell me that moziila will fix this issue ? Or its still under review !

Thanks.

Comment 17

[Emilio Cobos Álvarez [:emilio]]

Bug 1724719 should improve stuff further. I want to look at profiles once that's done.

Comment 18

[Sameer]

Hi,
What is the status ! its gonna fix by mozzila ?

Thanks.

Comment 19

[Jens Stutte [:jstutte]]

Hi Samer, you might want to check the latest nightly if bug 1724719 helped to some extent. Thanks!

Comment 20

[Sameer]

Okey ! Jens Stutte

Thanks

Comment 21

[Jens Stutte [:jstutte]]

(In reply to Sameer from comment #20)

Okey ! Jens Stutte

Thanks

So are you seeing an improvement? Thanks for your support

Comment 22

[Sameer]

Hi, Jens
Yes, now its looking little better, one more thing I have to say, that I am not a developer, So I don't have much knowledge about the things, I just found , and reported it, But support and investigation of report from your side, is amazing !
One more thing, Can you tell me that when this will be totally fixed by firefox ? And Pardon my English !
Thanks.

Comment 23

[Jens Stutte [:jstutte]]

(In reply to Sameer from comment #22)

    One more thing, Can you tell me that when this will be totally fixed by firefox ? 

Bug 1724719 is fixed in Version 93, which will be released in early October (see https://wiki.mozilla.org/Release_Management/Calendar). Thanks!

Comment 24

[Jens Stutte [:jstutte]]

Fixed by the fixed blocking bugs, it seems.

Comment 25

[Sameer]

Hi, Jens
I am just too happy to hear that, this will be patched in upcoming updates !
There is any hall of fame or bug bounty program for this reports ? If there please tell me , it
Will be awsomee for me to, see my name on mozzila's hall of fame !

Thanks.

Comment 26

[Jens Stutte [:jstutte]]

There is a bounty program for security bugs only. In the normal bugs case, you are just visible in bugzilla (which is already public and kind of our "hall of fame"!).

Comment 27

[Sameer]

Hi, Jens
Can you share the link for , where I am visible ! And thanks for the support ! And maybe it can have some impect as secutiy, maybe if attacker send a lot of emails with this type of symbols ! Which can crash users, So users can. Shift to different browser ,which can lead to loss in customers of Firefox , anyway thanks for the support ! And I have to verify the report and close it? or its already done by you?

Thanks. !

Comment 28

[Jens Stutte [:jstutte]]

I already closed it, thanks. Unless you demonstrate the possibility to provoke a crash this way (and this crash is actually bad enough to be classified as a security bug) we see this just as a performance improvement - still nice to have, obviously. And the link to share is just the link to this bug - it's public.