1456581 - Gmail Sent folder locks up browser for minutes

Status: NEW

(Core :: Layout: Text and Fonts, enhancement, P3)

Description

[Gian-Carlo Pascutto [:gcp]]

Attachment: profile.json

Clicking on some emails in my Gmail sent folder locks up the tab for over a minute.

It looks like Thunderbird tried to save a GPG encoded draft (of a large mail with pictures) and it stuck there. Gmail displays the contents when opening the mail thread. Our rendering of such is...not fast.

Profile is attached. Seems we lock up for 92 seconds in layout.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

I tested Chrome, and while it's not exactly fast here, it displays the Gmail page (instead of a spinner) in about 5 seconds, and finishes in about 15 seconds.

Comment 2

[Xidorn Quan [:xidorn] UTC+11]

The profile isn't very actionable... It shows PresShell::DoReflow takes 20s, but nothing about what's happening inside.

It would be great if you have a profile which can show more details inside that.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Any advice how to do that?

Comment 4

[Xidorn Quan [:xidorn] UTC+11]

I actually have no idea why your profile doesn't have anything inside. It normally should have deeper stack information unless everything happens in PresShell::DoReflow directly, which is unlikely.

Could you probably try reproducing this on a nightly build and capture a profile?

Comment 5

[Gian-Carlo Pascutto [:gcp]]

The profile was captured on a Nightly build :-/

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Hi gcp, thanks for reporting. Can you capture another profile, and upload it to perf.html please? It's kinda hard to work with profiles as bug attachments.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

Profile uploaded here:
https://perfht.ml/2rsjZMg

Comment 8

[Xidorn Quan [:xidorn] UTC+11]

The new profile shows 47s under reflow marker, in which nsLineBreaker::FlushCurrentWord takes 25.3s, nsLineBreaker::AppendText takes 7.6s. Sounds like we have some trouble with line breaker here. nsTextFrameUtils::TransformText also takes 2.2s.

We are probably calling nsTextFrame::EnsureTextRun too much? The total time under nsTextFrame::EnsureTextRun is 46.7s, which is almost all of the sampled 47s, so it is probably an issue in text layout.

Comment 9

[Xidorn Quan [:xidorn] UTC+11]

It would probably be useful if you can share the content of the email... the encrypted form is probably enough if that's what causing this issue. Probably upload the email as attachment here?

Comment 10

[Gian-Carlo Pascutto [:gcp]]

Attachment: hang.eml

Comment 11

[Gian-Carlo Pascutto [:gcp]]

Trying to copy-paste it locked up Chrome, so clearly this isn't exactly an optimized path in any browser.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Looks like xidorn beat me to the analysis.