Closed Bug 1759393 Opened 2 years ago Closed 2 years ago

Firefox stops rendering videos (the whole web-page) after 10 seconds when in background

Categories

(Core :: Audio/Video: Playback, defect)

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 98
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox98 + wontfix
firefox99 + wontfix
firefox100 + wontfix

People

(Reporter: dangerousgoal, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

This happens in Firefox 98.0 (Build ID: 20220304153049) and Nightly 100.0a1 (Build ID: 20220313093807) with a fresh profile. Doesn't happen in Firefox 97.0.2
OS is Windows 10

  1. Open Firefox 98 or Nightly
  2. Open a video to observe more clearly (youtube or twitch, happens for both)
  3. Change to another window so that the firefox window is not visible (happens in both full-screen and small window if it is hidden behind another window, even if that window is another firefox window and not full-screen)
  4. Wait for more than 10 seconds, the sound continues
  5. Change back to Firefox window (or use Win+Tab to open task view) to see the result (you can see it happen live in task view, that is how I timed it to be exactly 10 seconds)

Actual results:

After going back to Firefox, the web page is frozen for a split second and then the video jumps to a completely new frame.
This is very annoying while watching videos/livestreams.

Expected results:

Firefox should continue rendering the videos/web-pages in the background.
This may be a power saving feature but I am on desktop and have no battery-life concerns.
Since it happens after exactly 10 seconds each time, it must be intentional.
Is there a flag or option to disable this behaviour?

Component: Untriaged → Performance
Product: Firefox → Core

Setting this to NEW as I managed to replicate on Windows 10 on the latest versions of Nightly 100, Firefox 98, and Firefox 99 following the STR from Comment 1.

This is noticeable after using both Windows + Tab and Alt+Tab keyboards to switch between windows after a time period of 10 seconds or more.

Narrowed regression window to:
Last good revision: 1863bc09aef91f72fa72f01c1fcd70c64804d8d3
First bad revision: 0de6f75576d0d3e32d3ed8baa128dadfb39b9d4f

Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1863bc09aef91f72fa72f01c1fcd70c64804d8d3&tochange=0de6f75576d0d3e32d3ed8baa128dadfb39b9d4f

Severity: -- → S3
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox100: --- → affected
status-firefox98: --- → affected
status-firefox99: --- → affected
status-firefox-esr91: --- → unaffected
Component: Performance → DOM: Core & HTML
Ever confirmed: true
Keywords: regression

FWIW, setting widget.windows.window_occlusion_tracking.enabled to false fixed the problem in Firefox98 and Nightly100.0a1 Windows10.

(In reply to Alice0775 White from comment #2)

FWIW, setting widget.windows.window_occlusion_tracking.enabled to false fixed the problem in Firefox98 and Nightly100.0a1 Windows10.

I can confirm that this flag changes the behaviour to what I desire. Thanks!

Per comment #2, it seems something related to occlusion tracking in Windows.
sotaro, would you mind taking a look? Thanks!

Blocks: 1688997
Flags: needinfo?(sotaro.ikeda.g)

window occlusion could be disabled by setting pref widget.windows.window_occlusion_tracking.enabled to false from about:config.

See Also: → 1750629

Hi Sotaro! When did we flip on widget.windows.window_occlusion_tracking.enabled by default? I'm still interested in knowing why users started to see this behavior in FX 98. Thank you.s

:simona.marcu, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Flags: needinfo?(simona.marcu)
Flags: needinfo?(simona.marcu)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)

Hi Sotaro! When did we flip on widget.windows.window_occlusion_tracking.enabled by default? I'm still interested in knowing why users started to see this behavior in FX 98. Thank you.s

It was enabled by default for Fx98 in bug 1750491.

tracking-firefox100: --- → +
tracking-firefox98: --- → +
tracking-firefox99: --- → +
Regressed by: 1750491

FWIW I don't think this is a bug. We're telling YouTube that it's fully occluded and it's stopping video decoding, so I'm not sure if there's much to do on our end.

window occlusion was already enabled on MacOS, since MacOS natively supports window occlusion. And video playback on occluded window caused the same symptom.

Flags: needinfo?(sotaro.ikeda.g)

Moving to Audio/Video playback component according to comment 12. Please feel free to move back if I got something wrong.

Severity: S3 → --
Component: DOM: Core & HTML → Audio/Video: Playback
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.