Open Bug 1750449 Opened 2 years ago Updated 2 years ago

Firefox prevented idle computer from turning off display and locking

Categories

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

Firefox 96
defect

Tracking

()

People

(Reporter: owenw4rd, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: good-first-bug)

Attachments

(1 file)

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

Steps to reproduce:

FF was running in the foreground with no video or audio playing.
This was the active web site: www.rt.com/news
Under power management, the screen is set to turn off after 30 minutes which also locks windows (sleep is not enabled.)

Actual results:

After 10 hours the display never turned off and windows was still unlocked.
FF was still the active application.

Expected results:

Screen should have turned off after 30 minutes. Windows should have locked.
FF should not prevent Windows power management from turning off the display and locking the computer if no video or audio is playing, regardless of which web site is active.
This is a power and security issue.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

The rt.com site has a short embedded mp4 video playing (not a .GIF) in a loop with no audio. That appears to be what is causing FF to prevent the computer display from shutting off.

Thanks a lot for reporting the issue! Could you please follow the instructions in https://support.mozilla.org/en-US/kb/block-autoplay and check the Autoplay settings? If the default or rt.com is set to allow audio and video, please change it to block and see if the machine will go to sleep as expected.

Flags: needinfo?(owenw4rd)

(In reply to owenw4rd from comment #2)

The rt.com site has a short embedded mp4 video playing (not a .GIF) in a loop with no audio. That appears to be what is causing FF to prevent the computer display from shutting off.

We won't request wakelock for no audio videos. Could you please to use powercfg -requests to see what wakelock Firefox requests when you're browsing rt.com?

Thanks.

The attached file archive is a recent page from rt.com/russia/ that displays an embedded .mp4 video with no audio that runs in a loop.

Running powercfg shows it would probably keep the display from turning off.

powercfg -requests

DISPLAY:
[PROCESS] \Device\HarddiskVolume5\Program Files (x86)\Mozilla Firefox\firefox.exe
display request

The Activity Monitor on macOS shows that Firefox would prevent sleep there too on this page.

Flags: needinfo?(owenw4rd)

Thank for providing a test case!

I can reproduce that on all platforms. In the RT page, Firefox would be playing a muted video, which requests a video wakelock. That wakelock would be released if the page contains video goes to background.

However, if users scroll the page, and that video isn't in the viewport anymore. In this situation, Firefox should release that wakelock because now there is no any playing video visible to users. We only update wakelock when (1) updating media info (2) audible status changes. We should also check whether we need to update the wakelock when a video element's visibility changes, in order not to request a wakelock for an invisible video.

Blocks: wakelock
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: good-first-bug
Priority: -- → P3

(In reply to Alastor Wu [:alwu] from comment #6)

Thank for providing a test case!

I can reproduce that on all platforms. In the RT page, Firefox would be playing a muted video, which requests a video wakelock. That wakelock would be released if the page contains video goes to background.

However, if users scroll the page, and that video isn't in the viewport anymore. In this situation, Firefox should release that wakelock because now there is no any playing video visible to users. We only update wakelock when (1) updating media info (2) audible status changes. We should also check whether we need to update the wakelock when a video element's visibility changes, in order not to request a wakelock for an invisible video.

IMO an embedded muted looped video should not trigger a wakelock, even if the video is visible on the foreground tab.

On FF for iOS this RT page didn't prevent sleep, but it does in FF for Windows.

https://www.rt.com/russia/547401-kasatonov-warship-northern-fleet-exercises/

(In reply to owenw4rd from comment #7)

IMO an embedded muted looped video should not trigger a wakelock, even if the video is visible on the foreground tab.

User can also mute a video on Youtube and make it loop and playing, and in this case we should keep video wake lock even if it's muted and loop.

There are too many different situations and no one rule can perfectly fit them all. So what should we do is only requesting video wakelock when video is visible. (But for GIFs video, we won't request wakelock for them)

On FF for iOS this RT page didn't prevent sleep, but it does in FF for Windows.

That is a totally different thing, On iOS, we don't use Gecko, and WebKit would block all autoplay by default, so that page doesn't play any video on Firefox on iOS.

Do we still need someone to look at this? Because I'd be willing to

Free feel to take it, I'm happy to mentor. You can check comment6 for some information first.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: