<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Updated

•

2 months ago

Severity: -- → S3

Comment 9

•

2 months ago

Glenn, can you take a look?

Flags: needinfo?(mozilla)

Updated

•

2 months ago

Duplicate of this bug: 2032772

Comment 11

•

2 months ago

Bug 2032772 is very similar, other than that it notes even with HW accel there is in fact still very high CPU churn too, just which is magnified even further in SW.

Georgi H. Yordanov

Comment 12

•

2 months ago

(In reply to Lee Salzman [:lsalzman] from comment #11)

Bug 2032772 is very similar, other than that it notes even with HW accel there is in fact still very high CPU churn too, just which is magnified even further in SW.

Closing my earlier-reported Bug 2032772 was actually a correct move. Update as of 21 Apr 2026, before Firefox 149.0.2 was updated to 150.0.0:

Perhaps some microupdate occurred in the meantime because the CPU hogging by Firefoxes' GPU process stopped while part of Google's AI Search page was still seen in the background. I haven't made any changes to my Firefox Settings or Extensions.

Not an issue in v.150.0.0, either.

Comment 13

•

2 months ago

Attached file Bug 2033282 - Skip composite_native when dirty rects is empty (obsolete) — Details

Phabricator Automation

Updated

•

2 months ago

Assignee: nobody → mozilla

Status: NEW → ASSIGNED

Comment 14

•

2 months ago

This seems to fix the high CPU usage for this scenario on swgl. I have been unable to test on CI as try server is just returning 502/503 at the moment, so will run a more thorough test later.

Flags: needinfo?(mozilla)

Updated

•

2 months ago

Updated

•

2 months ago

Duplicate of this bug: 2030924

Comment 16

•

2 months ago

Attached file Bug 2033282 - Skip SwCompositor composition when no native compositor and dirty region is empty (obsolete) — Details

Phabricator Automation

Updated

•

2 months ago

Attachment #9572718 - Attachment is obsolete: true

Jamie

Comment 17

•

1 month ago

I have the same issue, the only way I found to avoid it was with a uBlock filter to stop google's animation from triggering via:
||www.gstatic.com/searchbox-team/eclipse_wave_blurred_rects_f2dcf436ae9c2b05017fd88933a1b6ad.png$image

It seems to stem from the SVG https://www.gstatic.com/searchbox-team/eclipse_wave_blurred_rects_f2dcf436ae9c2b05017fd88933a1b6ad.png

Over about 5 seconds, Firefox profiling recorded:

x596 MozAfterPaint events
x600 DisplayList / WebRender display list updates
x598 paints of https://www.gstatic.com/searchbox-team/eclipse_wave_blurred_rects_f2dcf436ae9c2b05017fd88933a1b6ad.png
CSS animation named rotate-glow-rects
Target element: image ... class='Wrq4d' with animation property: rotate & compositor: true

Hope it helps

Phabricator Automation

Updated

•

1 month ago

Attachment #9573261 - Attachment is obsolete: true

Updated

•

1 month ago

Priority: P1 → --

Robert

Comment 18

•

1 month ago

I have the same issue with AI overview when expanding show more. Firefox main pid goes from ~%5 to 500% CPU thread usage while staying on the same tab.
I'm on firefox-150.0-1.fc44.x86_64, Mesa 26.0.3-4, amd-gpu-firmware-20260410-1.fc44.noarch

Comment 19

•

1 month ago

Can confirm this issue on 150.0.1 under Linux. It's pretty bad as, if you leave a tab with this active, it can quickly kill your battery life.

Comment hidden (me-too)

MintMark

Comment 21

•

1 month ago

Also seeing this with 150.0.1 on Ubuntu 22.04.5. I have to be careful where I leave my open tabs, but at least I know what to look for now.

Dmytro

Comment 22

•

1 month ago

FF 150.0.2 is also affected. Blocking www.gstatic.com/searchbox-team/eclipse_wave_blurred seems to solve the issue for now.

g4x86

Comment 23

•

1 month ago

Can confirm this issue on recent Firefox updates about a month ago on Ubuntu-based Linux too. The problem remains in the latest v150.0.3

tlatorre9

Comment 24

•

1 month ago

Seeing the same thing on Fedora 44 Firefox version 150.0.3 (64-bit). Uses all available CPU.

Jeff Muizelaar [:jrmuizel]

Comment 25

•

1 month ago

Still the same on FF 151.0 on win11 64. Uses 50% cpu with the FF GPU process
Blocking www.gstatic.com/searchbox-team/eclipse_wave_blurred still works

Comment 26

•

1 month ago

I'm curious why so many of you are getting Software WebRender. Can you attach the contents of about:support?

Comment 27

•

1 month ago

(In reply to Jeff Muizelaar [:jrmuizel] from comment #26)

I'm curious why so many of you are getting Software WebRender.

I'm using hardware WebRender and have this issue.

Comment 28

•

1 month ago

Still the same in 151.1

This must be eating batteries in laptops!

Bartłomiej Bąkowski

Comment 29

•

1 month ago

I can reproduce this on Arch Linux / Hyprland / Wayland with Firefox 151.0.
https://share.firefox.dev/3RluP5K

System / graphics:

Firefox: 151.0, Arch Linux package
OS: Arch Linux, kernel 7.0.9-arch1-1
DE/compositor: Hyprland 0.55.2, Wayland
GPU: AMD Radeon 890M Graphics
Driver: Mesa/radeonsi 26.1.1
Compositing: WebRender
This is not Software WebRender.
Display: 2880x1800 @ 120 Hz, scale 2.0

Reproduction:

Open Google Search in Firefox.
Trigger AI Overview / click "Show more" or an AI Overview preview.
CPU/GPU usage rises and remains high while the AI Overview animation is active.

Workaround / confirmation:
Running this in the page console immediately stops the issue:

document.querySelectorAll('.Wrq4d').forEach(el => {
  el.style.animation = 'none';
  el.style.transition = 'none';
});

For a persistent workaround, add this to [uBlock Origin -> My filters]:

www.google.com##.Wrq4d:style(animation: none !important; transition: none !important;)
www.google.pl##.Wrq4d:style(animation: none !important; transition: none !important;)

Profiler observations [by: codex 5.5]:

The captured process is an Isolated Web Content process for the Google Search tab.
GeckoMain is the only significantly busy thread in that content process.
The profile shows repeated refresh-driver/rendering work after expanding AI Overview:
- RefreshDriverTick
- ViewManagerFlush
- Styles
- DoFlushPendingNotifications
- Image Paint
- DisplayList
- WrDisplayList / ForwardDPTransaction
Tick reason appears as:
HasPendingRenderingSteps(Update animations and send events)
Markers point to a CSSAnimation targeting:
image class="Wrq4d"
There are animationiteration events for that same element.
Disabling the animation on .Wrq4d stops the CPU/GPU load immediately.

Comment 30

•

25 days ago

Any chance of seeing an update to the Priority of this? I'd argue the Severity should be S2 based on the number of user's affected; this is amazingly frustrating and fits well in the Examples of S2 bugs at https://firefox-source-docs.mozilla.org/bug-mgmt/guides/severity.html.

Updated

•

25 days ago

Severity: S3 → S2

Comment 31

•

25 days ago

This is probably a silly question, but how do I reproduce this now? I'm not much of a google search user - but I don't seem to get any AI Overview now for any searches I tried? Has this been replaced by the AI Mode tab or is it still possible to repro this?

Comment 32

•

25 days ago

Hiro, Emilio, is this is an offscreen animation, is it feasible to detect and stop the animation occurring on the content process side? Is the content process meant to prevent offscreen animations from triggering composites, or does it rely on webrender's visibility culling to reduce the work and skip composites?

Flags: needinfo?(hikezoe.birchill)

Flags: needinfo?(emilio)

Hiroyuki Ikezoe (:hiro)

Comment 33

•

25 days ago

(In reply to Glenn Watson [:gw] from comment #32)

Hiro, Emilio, is this is an offscreen animation, is it feasible to detect and stop the animation occurring on the content process side? Is the content process meant to prevent offscreen animations from triggering composites, or does it rely on webrender's visibility culling to reduce the work and skip composites?

Basically it can. And indeed we have throttled offscreen animations. But given that the machinery doesn't work well on this specific case, there's something the machinery can't handle. Anyways, a reduced test case would tell us why it doesn't work.

Flags: needinfo?(hikezoe.birchill)

cmicek325

Comment 34

•

24 days ago

(In reply to Glenn Watson [:gw] from comment #31)

This is probably a silly question, but how do I reproduce this now? I'm not much of a google search user - but I don't seem to get any AI Overview now for any searches I tried? Has this been replaced by the AI Mode tab or is it still possible to repro this?

This happens to me too every so often. (I think it might be Google trying to offload/redistribute resources for AI usage?) Repeating the search in a private window usually gets AI mode to show up there.

egor.duda

Comment 35

•

24 days ago

(In reply to Glenn Watson [:gw] from comment #31)

This is probably a silly question, but how do I reproduce this now? I'm not much of a google search user - but I don't seem to get any AI Overview now for any searches I tried? Has this been replaced by the AI Mode tab or is it still possible to repro this?

Created clean firefox profile (I'm using FF 140.11.0esr (64-bit))
Opened url https://www.google.com/search?q=test+ai+search
Clicked on "Show more..." button, CPU usage goes way up
Opened Developer Tools, on inspector tab searched for 'blurred' (found one <image> element)
When mouse hovers over this <image ...> in inspector, selection on page is being constantly and quickly updated, changing size and layout

Emilio Cobos Álvarez [:emilio]

Comment 36

•

24 days ago

(In reply to Glenn Watson [:gw] from comment #31)

This is probably a silly question, but how do I reproduce this now? I'm not much of a google search user - but I don't seem to get any AI Overview now for any searches I tried? Has this been replaced by the AI Mode tab or is it still possible to repro this?

It's still reproduce-able in the same way for me. I just ask 'what is beta testing' from the normal google search page (www.google.com), wait for the AI overview to appear at the top of the list of search results and click the show more button immediately below it.

FF 151.02
Win11 home 10.0.26200

Comment 37

•

24 days ago

Yeah, I can repro when logged in. The TLDR is that we have code to detect invisible animations and throttle them, but as Hiro noted is not working in this case.

I did some digging. The element is pretty on-screen tbh, and the only thing that hides the animation seems to be an opacity: 0 on the root <svg> element of that subtree.

However, that <svg> has:

animation: close-eclipse .3s cubic-bezier(0.2,0,0,1) forwards;

Where:

@keyframes close-eclipse {
  0% {
    display:block;
    opacity:1
  }
  99.99% {
    display:none;
    opacity:0
  }
  to {
    display:none;
    opacity:0
  }
}

We're detecting that the opacity: 0 subtree root animates opacity and failing to throttle here.

But also, display: none is supposed to apply and it'd stop this descendant animation too.

So there are two things that would fix this:

Bug 1834877, which would allow display: none in those keyframes to apply and stop rendering this <image>.
Bug 2043543, which would allow our opacity: 0 throttling to cover this case.

Depends on: 1834877

Flags: needinfo?(emilio)

Emilio Cobos Álvarez [:emilio]

Updated

•

24 days ago

Depends on: 2043543

Emilio Cobos Álvarez [:emilio]

Comment 38

•

24 days ago

(TLDR I don't think we should consider this a WebRender bug)

Hiroyuki Ikezoe (:hiro)

Comment 39

•

24 days ago

Nice find! So this is not offscreen animation case at all. This is just an animation fading out with fill:forwards.

Though Emilio mentioned this is not a WebRender bug, I wonder why WebRender takes so much CPU for invisible animation? That sounds odd.

Summary: High CPU consumption on google search result expansion - WR sw_compositor recomposites the window due to offscreen animation → High CPU consumption on google search result expansion - WR sw_compositor recomposites the window due to invisible animation

Calin Tanase

Updated

•

24 days ago

See Also: → https://github.com/webcompat/web-bugs/issues/220842

James Barrante

Comment 40

•

21 days ago

(In reply to Hiroyuki Ikezoe (:hiro) from comment #39)

Nice find! So this is not offscreen animation case at all. This is just an animation fading out with fill:forwards.

Though Emilio mentioned this is not a WebRender bug, I wonder why WebRender takes so much CPU for invisible animation? That sounds odd.

Confirming for 151.0.2 (aarch64) / MacOS Tahoe 26.5 (25F71), with Firefox h/w acceleration happily enabled.

The underlying scope appears much broader than the Google search AI context. IIRC, this issue has been around for quite some time, predating this bug report.

To Hiro's point: The fact that WebRender burns this much CPU on an invisible animation points to a broader issue in the compositor itself, rather than just a DOM throttling failure. Testing shows that adding a single, simple CSS animation to just one DOM element on an otherwise dead-static page causes a CPU spike in the Firefox GPU helper process, for as long as the animation runs and the tab remains active — even if the browser window is in the background, thus making this a case for offscreen animation.

Exhibit A, and this may qualify as reduced test case: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Animations

Not saying CPU utilization shouldn't spike at all — it's a matter of proportion. Elevated CPU load is totally fine for running something like QuakeJS, but rendering decorative animations shouldn't significantly ramp up CPU temperatures. I hope this can be fixed.

Walter K.

Comment 41

•

20 days ago

Here is an additional profile if needed: https://share.firefox.dev/4dHFDUt
Total CPU goes above 95% and the machine's fan is on constantly when the Google page is in the current tab.

Updated

•

14 days ago

Assignee: mozilla → nobody

Status: ASSIGNED → NEW

Component: Graphics: WebRender → DOM: Animation

Hiroyuki Ikezoe (:hiro)

Comment 42

•

12 days ago

Has someone tried a recent nightly? I am hoping this bug has been fixed by bug 2043543.

Comment 43

•

12 days ago

Still the same for me with FF 151.0.4 Win11 home 10.0.26200

egor.duda

Comment 44

•

12 days ago

(In reply to Hiroyuki Ikezoe (:hiro) from comment #42)

Has someone tried a recent nightly? I am hoping this bug has been fixed by bug 2043543.

It looks somewhat better, but not fully:

Got latest Nightly for linux x86_64 153.0a1 (2026-06-10) (64-bit)
Created new profile
Opened https://www.google.com/search?q=google+ai+search in one tab and about:processes in other
Pressed "Show more" button on google page
On about:processes multiple WRWorkerLP#n threads each consume ~ 3% cpu (before "Show more" button they all were idle)
Generally, before "show more" button, total cpu in about:processes was about 5-10%, after -- 40-50%
Opened Developer Tools->Inspector, found svg containg https://www.gstatic.com/searchbox-team/eclipse_wave_blurred_rects_f2dcf436ae9c2b05017fd88933a1b6ad.png image
When mouse hovers over this <image ...> in inspector, selection on page is being constantly and quickly updated, changing size and layout
right click on svg -> context menu->delete node
After that WRWorkerLP#n threads became idle again and cpu usage dropped back to 5-10%

Comment 45

•

12 days ago

(In reply to egor.duda from comment #44)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #42)

Created new profile

Opened https://www.google.com/search?q=google+ai+search in one tab and about:processes in other

Pressed "Show more" button on google page

On about:processes multiple WRWorkerLP#n threads each consume ~ 3% cpu (before "Show more" button they all were idle)

Generally, before "show more" button, total cpu in about:processes was about 5-10%, after -- 40-50%

Opened Developer Tools->Inspector, found svg containg https://www.gstatic.com/searchbox-team/eclipse_wave_blurred_rects_f2dcf436ae9c2b05017fd88933a1b6ad.png image

When mouse hovers over this <image ...> in inspector, selection on page is being constantly and quickly updated, changing size and layout

right click on svg -> context menu->delete node

After that WRWorkerLP#n threads became idle again and cpu usage dropped back to 5-10%

Exactly the same to the letter under FF 151.0.4 on Win11 home 10.0.26200

tlatorre9

Comment 46

•

12 days ago

Same problem with all 4 cores spinning at 100% on Fedora 44 with Firefox 151.0.1. I'm curios, how is it that a single animation can use 100% of 4 cores?

Jeremy Melanson

Comment 47

•

8 days ago

(In reply to Jamie from comment #17)

I have the same issue, the only way I found to avoid it was with a uBlock filter to stop google's animation from triggering via:
||www.gstatic.com/searchbox-team/eclipse_wave_blurred_rects_f2dcf436ae9c2b05017fd88933a1b6ad.png$image

It seems to stem from the SVG https://www.gstatic.com/searchbox-team/eclipse_wave_blurred_rects_f2dcf436ae9c2b05017fd88933a1b6ad.png

<mask>
<linearGradient>
<clipPath>
<filter>
<feGaussianBlur stdDeviation="15">
<use>
<image class="Wrq4d">

Over about 5 seconds, Firefox profiling recorded:

x596 MozAfterPaint events
x600 DisplayList / WebRender display list updates
x598 paints of https://www.gstatic.com/searchbox-team/eclipse_wave_blurred_rects_f2dcf436ae9c2b05017fd88933a1b6ad.png
CSS animation named rotate-glow-rects
Target element: image ... class='Wrq4d' with animation property: rotate & compositor: true

Hope it helps

It looks like this worked for me (Firefox 151.0.4 Linux). So far, so good at least.

Comment 48

•

3 days ago

For what it's worth, I no longer experience the issues with 152 under Linux.