Closed Bug 1914874 Opened 1 year ago Closed 1 year ago

The privileged content process runs invisible animations that get painted for about 20s after startup

Categories

(Firefox :: New Tab Page, defect)

defect

Tracking

()

VERIFIED FIXED
131 Branch
Performance Impact ?
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox129 --- unaffected
firefox130 + verified
firefox131 --- verified

People

(Reporter: florian, Assigned: thecount)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: perf:resource-use, regression)

Attachments

(1 file)

Here's a startup profile of a local build from today's mozilla-central on my macbook: https://share.firefox.dev/478SM44

Notice that there are animations going on for about 20s even though nothing visible changes on screen. This is visible with the markers in the parent process on the Compositor and Renderer threads, and on the Privileged Content process main thread.

The animations happen in the preloaded (but invisible) about:newtab.

What I'm seeing in the profile here looks very similar to what we were seeing in the profiles when investigating bug 1908163 comment 6, so it's very likely the regression comes from bug 1908163.

Flags: needinfo?(sdowne)
See Also: → 1908163

Maybe the easiest fix here is put the animation classname behind an intersection observer, so it only starts once it is seen?

Flags: needinfo?(sdowne)

(In reply to Scott [:thecount] Downe from comment #2)

Maybe the easiest fix here is put the animation classname behind an intersection observer, so it only starts once it is seen?

Might be worth a try? I'm not sure if it will work because the preloaded about:newtab is kept in a special semi-visible state all the time so that it appears very quickly.

The bug is marked as tracked for firefox130 (beta). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still isn't assigned.

:amy, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Flags: needinfo?(achurchwell)
Assignee: nobody → sdowne

I tested the patch locally on my Macbook Pro at Scott's request.

Here's a profile of the first 24s after startup on my local mozilla-central build without the patch and on the same local build with the patch applied.

The profiles confirm the patch fixes the bug.

Additionally, these profiles include power data, so we can estimate the size of the regression:

  • Without the patch, startup used 5.1 mWh (3.8 mWh in the parent and 1.3 mWh in the Privileged Content process).
  • With the patch, startup used 3.9 mWh (3.3 mWh in the parent and 0.6 mWh in the Privileged Content process).

Based on these numbers, it seems the regression increased the power use of Firefox startup by about 30% on my machine.

Pushed by sdowne@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2275ee345fd3 Newtab stopping animation happening off screen r=home-newtab-reviewers,maxx
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 131 Branch

Comment on attachment 9421015 [details]
Bug 1914874 - Newtab stopping animation happening off screen

Beta/Release Uplift Approval Request

  • User impact if declined: Increased energy use for 20s after Firefox startup.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: https://phabricator.services.mozilla.com/D220266 includes a "TEST PLAN".

Startup profiling (enable the profiler toolbar icon first by going to profiler.firefox.com, and then start the browser with MOZ_PROFILER_STARTUP=1 in the environment) and verifying how many animations markers we have in the privileged content process is also a very good way to verify. This is what I did in comment 6.

  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): I hesitated between low and medium. Low because the change seems to be straight forward and mostly in CSS, and gives me the impression that the worst that could happen if something breaks is not running an animation that didn't exist before.
    Medium because I'm not sure about test coverage.
  • String changes made/needed:
  • Is Android affected?: No
Attachment #9421015 - Flags: approval-mozilla-release?
Flags: qe-verify+

I've replicated this issue using Nightly 131.0a1 (2024-08-26) on macOS 13 following the STR from Comment 9 (startup profile https://share.firefox.dev/3yY31LW).
Verified as fixed in the latest Nightly 131.0a1 (2024-08-28) version on Windows 10 x64, macOS 13, and Ubuntu 22.04, as the issue no longer occurs.

Flags: qe-verify+

Comment on attachment 9421015 [details]
Bug 1914874 - Newtab stopping animation happening off screen

Approved for 130.0rc2

Attachment #9421015 - Flags: approval-mozilla-release? → approval-mozilla-release+

Verified as fixed in the latest Firefox 130.0-build2 version on Windows10 x64, macOS 13, and Ubuntu 22.04 where the issue no longer occurs.
I followed the same steps From Comment 9(installing the profiler, opening the Firefox profile from cmd/terminal and checking the Privileged Content Process under the Market Chart tab). Please see also the startup profile uploaded on macOS 13 https://share.firefox.dev/3XpLZ2o.

Status: RESOLVED → VERIFIED
Regressions: 1917698

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #4)

:amy, could you please find an assignee for this tracked bug?

Looks like we can cancel bugbot's needinfo^, given that this was later assigned & fixed.

While I'm here, though, I'll note that this bug's landing seems to have introduced a regression, which I just filed as bug 1917698.

Flags: needinfo?(achurchwell)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: