Steps to reproduce:

1. Start Firefox Nightly on maCOS with a fresh profile.
2. Observe its CPU usage using the Activity Monitor and wait for it to settle down to about 1.3 to 1.6%.
3. Click the hamburger button to open the menu panel.
4. Close the panel again, and monitor the CPU usage.

Expected results:
The CPU usage should fall back down to the previous levels.

Actual results:
The CPU usage stays around at least 6.8%.

Now, if you click the new "Firefox Account" button so that the "Take Firefox with You" panel opens, and close that panel again, the problem goes away: CPU usage settles back down to 1.3% to 1.6%.

If you don't open that panel, Firefox will continue to drain your battery at twice the usual rate during idle.

Here's a profile of this happening: https://perfht.ml/2VeUFq5
Note the cyan markers in the parent process main thread: These are restyle and reflow markers. They start firing around the five second mark, which is when I opened and closed the menu panel. Then they keep firing non-stop until the 27 second mark, which is when I opened and closed the Firefox Accounts panel.
The "cause callstack" in the restyle markers shows that the restyles are being scheduled because of a SMIL animation.
Searching for ".svg" in the call tree identifies the image chrome://browser/skin/fxa/choose-what-to-sync-devices.svg , which is the image that's shown in the Firefox Accounts panel when you're not logged in.

So what seems to be happening is that opening the menu panel initializes the Firefox Accounts panel, and until Gecko paints the SVG image in it, it thinks it needs to animate it, even though the panel is closed. This seems like a Layout bug.

As a short-term workaround, can we remove the spinning animation from choose-what-to-sync-devices.svg?

(In reply to Markus Stange [:mstange] from comment #0)

As a short-term workaround, can we remove the spinning animation from choose-what-to-sync-devices.svg?

I don't know, that'd be UX's call. I have to say it's almost impossible to see the spinning anyway, except in the dark theme, so I'd be fine with getting rid of it.

Are there other workarounds we could use, like display: none'ing the element until the panel is opened or something?

Great catch! Remove the animation and if you need help doing this, let me know.

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

Are there other workarounds we could use, like display: none'ing the element until the panel is opened or something?

That may also work, but it would need to be tested.

(In reply to Vijay Budhram from comment #4)

Thanks - Markus, can you confirm this works?

Confirmed, it works!

https://hg.mozilla.org/mozilla-central/rev/cb920b828002

Comment on attachment 9055486 [details]
Bug 1541314 - Remove animation from choose what to sync svg

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Bug 1524665
• User impact if declined: High CPU/battery usage once the hamburger is panel shown
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We're just removing the animations from the SVG file.
• String changes made/needed: none

Comment on attachment 9055486 [details]
Bug 1541314 - Remove animation from choose what to sync svg

Fix for a CPU issue caused by a new 67 feature, low risk patch, uplift approved for 67 beta 9, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/dff20faae9f4