1681984 - L10nMutations::FlushPendingTranslations() can block the UI when a macbook goes out of sleep

Status: RESOLVED FIXED

(Core :: Internationalization, defect, P2)

Description

[Florian Quèze [:florian]]

I have about:processes and about:performance in pinned tabs. When my macbook wakes after being suspended for a while, it takes sometimes a few minutes before I can interact with the UI. I've managed to capture profiles by enabling the profiler before letting the machine sleep, and capturing the profile as soon as the UI became responsive again.

https://share.firefox.dev/3n8Vgra - UI unresponsive for about 70s. Also notice that at the end of the unresponsive time, about 2GB of memory was released.

https://share.firefox.dev/37WBIjo - similar profile, but only 13s of unresponsiveness, likely because the machine didn't remain asleep for a long time.

Here's my best guess at what is happening: while the machine is asleep, JS code and timers keeps executing, so about:processes and about:performance are refreshed every 2s, and change their DOMs, in ways that require localization.
However, while the macbook is asleep, the refresh driver doesn't tick, so these translations don't get processed, and mPendingElements in L10nMutations.cpp grows enormously.

Possible solutions:

• (preferred) the mutation observer should pay attention to removal from the DOM of elements included in the mPendingElements list, and cleanup.
• (would solve the esponsiveness issue, but not the memory use issue) DOMLocalization::TranslateElements should check that an element is still in the DOM before translating it.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

Thanks Florian!

That's an excellent analysis and we definitely should address it!

Did you manage to get minimal STR for the behavior this way, or is it intermittent?

Comment 2

[Florian Quèze [:florian]]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #1)

Did you manage to get minimal STR for the behavior this way, or is it intermittent?

I've not intentionally tried to reproduce, but I encounter this pretty frequently. I even had a few occurences where the memory use of the parent process was above 12GB and the only way to recover was to kill Firefox.

I think this should be easy to reproduce on a macbook with power nap (ie. on a macbook asleep but connected to power Firefox will keep executing JS and timers, but not use the network or display anything on screen). Bug 1682043 is what makes hitting this bug frequent for me. So currently my guess at the steps to reproduce would be:

1. On a macbook, open about:performance and about:processes in tabs (only one of them should be enough, but with the 2 of them the problem will be more visible).
2. Make the window fullscreen (or watch a fullscreen video in a tab of the same window) to trigger bug 1682043. If bug 1682043 is fixed, keeping the about:processes tab in the foreground at the time the macbook is put to sleep should do, but I haven't verified.
3. Put the macbook to sleep, but keep it connected to power.
4. After a while, re-open the macbook and try to use Firefox. It will be unresponsive for a while (seconds to minutes).

Comment 3

[Kim Moir [:kmoir] ET]

Zibi I'm triaging these performance bugs (marked with whiteboard [qf]). Do you have further thoughts on this bug on next steps?

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

I don't. We have it scheduled for this quarter. If you believe we should bump the priority to address it ASAP, let me know!

Comment 5

[Florian Quèze [:florian]]

Note: the document.l10n.pauseObserving/resumeObserving calls added in bug 1694728 mean the steps in comment 2 won't reproduce anymore.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: Bug 1681984 - Remove elements from L10nMutation pendingElements when they're removed from observed roots. r?nordzilla

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/91cc3f246798
Remove elements from L10nMutation pendingElements when they're removed from observed roots. r=nordzilla,smaug

Comment 8

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/91cc3f246798

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

:florian - can you verify if the fix matches your expectations?

Comment 10

[Florian Quèze [:florian]]

I have not encountered this bug again.