1941693 - Firefox full screen video causes unusually high CPU usage / power draw on macOS when ProMotion is enabled until the mouse is hovered to the menubar

Status: UNCONFIRMED

(Core :: Graphics, defect, P3)

Description

[earthstamper]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Install any power monitoring or CPU monitoring tool that is visible from the menubar and display CPU usage or system power draw.

Verify that ProMotion is enabled in the display settings.

Change "Automatically hide and show the menubar" to Never.

Go to YouTube. Open any video. Double click to full-screen.
Do not move the mouse.

Actual results:

Observe higher power draw / CPU usage than usual.
When the mouse is moved to the top of the screen to trigger the title bar and left there for a couple of seconds, power draw will immediately go down and stay down, even after minimizing and re-minimizing the window. If another YouTube video is opened, the issue reappears.

Expected results:

Powerdraw does not change and stays constantly low when watching a video.

This phenomenon is not observed on chromium based browsers, which is why I assume this to be a Firefox issue.

Comment 1

[earthstamper]

I forgot to add that this does not occur when ProMotion is disabled.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Alastor Wu [:alwu]]

The fullscreen issue is related with gfx.

Comment 4

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:bhood, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Ashley Hale [:ahale]]

ProMotion sounds like it is the macOS equivalent of Dynamic Refresh Rate on Windows, the basis of these technologies is that when input events are coming in, the refresh rate of the laptop display is boosted to 120hz and is otherwise kept at 60hz to save energy.

The bug is not the higher power usage when input events come in, but the fact it stays locked at 120hz while the cursor is within the document area, which in fullscreen is the entire display (so it never goes down to 60hz).

I believe the ask here is that it should be 60hz when no input events are coming in, regardless of whether it is fullscreen and regardless of what is going on in the document area.

I'm not familiar enough with macOS to delve any deeper into this, and I am not sure whether this is arguably a gfx issue (we do own the vsync code, so it is arguable that it is gfx), or a widget issue (because it should depend on input).

Brad, do you have an idea on how we should proceed here?

Comment 6

[Brad Werth [:bradwerth]]

I'll try to replicate. In the meantime, I'd love to see a Mozregression on this, from somebody who can replicate it. We've changed menu code, changed fullscreen code quite a bit in the last two years. I won't be at all surprised if we've done something that has an incidental unwanted effect on power.

Comment 7

[earthstamper]

(In reply to Brad Werth [:bradwerth] from comment #6)

I'll try to replicate. In the meantime, I'd love to see a Mozregression on this, from somebody who can replicate it. We've changed menu code, changed fullscreen code quite a bit in the last two years. I won't be at all surprised if we've done something that has an incidental unwanted effect on power.

I've run mozregression and it said "not enough data for bisect", I was able to procure two builds adjacent to each other where it works and doesn't work.

Bad build: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=272d7188fe71c94facdcd15027c7b5385863315f&tochange=af07ced273d9f48af0409c2addff9adbc230374f

Good build: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=2d1b642cb391ae3675fd3960fdeec82b5706a2d1&tochange=af07ced273d9f48af0409c2addff9adbc230374f

That being sad, the most defining feature is that on the working build, firefox does not fullscreen into a new space on macos, instead, it fullscreens in the same space, kind of bypassing macOS's native fullscreen behavior

Comment 8

[Brad Werth [:bradwerth]]

The mozregression logs are mostly the same, and they both have Bug 1802193 in them, where we turned on native fullscreen. That indicates to me that this behavior has always been present since we turned on native fullscreen. Your note that the working build does not fullscreen into a new space is just an indicator that we are using the non-native fullscreen path.

Still not sure why I can't replicate the issue. I'll keep trying.

How about this? Would you please capture a profile of the high CPU usage, followed by the cursor-to-top return to normal CPU usage, upload the profile, and post the profile URL this Bug. To capture a profile, navigate to https://profiler.firefox.com and follow the instructions there. Use the "Graphics" preset and include screenshots, please.

Comment 9

[earthstamper]

(In reply to Brad Werth [:bradwerth] from comment #8)

The mozregression logs are mostly the same, and they both have Bug 1802193 in them, where we turned on native fullscreen. That indicates to me that this behavior has always been present since we turned on native fullscreen. Your note that the working build does not fullscreen into a new space is just an indicator that we are using the non-native fullscreen path.

Still not sure why I can't replicate the issue. I'll keep trying.

How about this? Would you please capture a profile of the high CPU usage, followed by the cursor-to-top return to normal CPU usage, upload the profile, and post the profile URL this Bug. To capture a profile, navigate to https://profiler.firefox.com and follow the instructions there. Use the "Graphics" preset and include screenshots, please.

I had to load a couple of video and put them in fullscreen until it showed up, but the profile captures a high power draw event at the end. Then I move the mouse to the menu bar, and after 3-4 seconds power draw goes down from 11-15W back to the normal 5-7W I would expect when playing a youtube video with Firefox.

Here the issue appears on the third video I play:

https://profiler.firefox.com/public/8sy83acxg38sckcgk4yb4gk18krj0jn8hcfcn9r/calltree/?globalTrackOrder=0dbc8a57164932&hiddenGlobalTracks=1wb&hiddenLocalTracksByPid=4133-0~4096-0~4176-0~22246-0~4127-0~21989-0~4128-0~14842-0~22245-0~14841-0~4132-01~4095-2wegiwk&thread=x3&v=16

Here the issue appears on the second video I play:

https://profiler.firefox.com/public/xngyw9whcfjd2w6skxkykwsk07r1jz2x5bdkv5g/calltree/?globalTrackOrder=0c5d6b281a9734&hiddenGlobalTracks=1wb&hiddenLocalTracksByPid=4133-0~4127-0~4176-0~4096-0~4132-01~14842-0~24418-0~4128-0~24398-0~24479-0~24397-0~4095-2wegiwk&thread=d&v=16

By including screenshots you mean ticking all these boxes when uploading the profile, right?

Include additional data that may be identifiable
Include hidden threads
Include hidden time range
Include screenshots
Include resource URLs and paths
Include extension information

Please let me know if you need anything else!

Comment 10

[Scott Macpherson]

I'd like to help in any way I can on this one. Energy consumption when watching full-screen video on Apple silicon Macs is my number one irritation with Firefox these days.

My very crude checks seem to confirm this conjecture: with ProMotion enabled watching a full-screen YouTube video lights up the "Performance" cores in Activity Monitor. With my screen's refresh rate pinned at 60Hz, Activity Monitor shows almost nothing using performance cores.

Firefox 153.0.1 (aarch64), macOS 26.6 (25G72), Apple M4.