Closed Bug 517870 Opened 12 years ago Closed 7 years ago
Video should disable screensaver during playback
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124; .NET CLR 2.0.50727; ffco7) Gecko/2009060215 Firefox/3.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199; .NET CLR 2.0.50727; ffco7) Gecko/2009060215 Firefox/3.0.11 During playback, fullscreen video should disable the screensaver to allow watching arbitrarily long videos uninterrupted. This is a feature that is common in native player and would be a leg up on flash-based players. Reproducible: Always There is a registry key that could be used for this purpose on Windows, but I'm not sure I like it for the same reasons given here: http://mailman.videolan.org/pipermail/vlc-devel/2008-December/054231.html but the workaround they came up with, while perhaps a bit hacky, would work fine here too.
The right way to do this on Windows would be to use SetThreadExecutionState(ES_DISPLAY_REQUIRED) (http://msdn.microsoft.com/en-us/library/aa373208%28VS.85%29.aspx). No need to touch the registry or send fake events regularly.
That MSDN page states that 'This function does not stop the screen saver from executing'. I have never used SetThreadExecutionState so I don't know if that's accurate...
Er, yeah the documentation is right. Calling SetThreadExecutionState(ES_DISPLAY_REQUIRED) just resets the idle idle timer, so it would need to be called regularly. Python testcase: import ctypes, time while True: ctypes.windll.kernel32.SetThreadExecutionState(0x00000002) time.sleep(10)
What you are testing is explained in the doc. The same call with ES_CONTINUOUS = 0x80000000 would not require the call to be made repeatedly (although it would potentially face the same problems as the reg key in the link I referenced earlier). The real question is whether the screen saver comes on after the call or if this only effects the screen on/off state. I am about to test, but I am stuck on a PC where the screen saver is locked at 15 min so it will take a little longer than it should. If anyone can test in less time, feel free.
See http://stackoverflow.com/questions/463813/programmatically-prevent-windows-screensaver-from-starting for a discussion of how to prevent the screensaver.
Confirmed: the documentation is correct. After 15 min, my screen saver came up even after the call to SetThreadExecutionState but the screen never turned off so the call did work. Thank goodness for lunch or I would have never had 15 minutes to let my machine idle in the middle of the day!
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
On Linux, this depends on the desktop environment. The GNOME screensaver can be deactivated using DBus (org.gnome.ScreenSaver IIRC). I guess the same is true for KDE4's screensaver, but most likely not xscreensaver.
Telling the OS to disable screen savers seems dangerous because it is unlikely to revert if Firefox crashes while viewing the video. I think maybe we should just send a dummy keystroke every ~55 seconds (with 1 minute being the lowest screensaver time limit). If we crashed while viewing the video then the screensaver would come back on and no settings would be inconsistent.
cpearce: Do you think you will be able to take this bug? It seems that Flash disables the screensaver/system-sleep while playing videos.
I'm likely occupied for next month or two, so if someone wants to take this bug, that's fine. However we should try to use the same back-end code/API as they're going to use in bug 697132, so we'll need to liaise with those guys on implementing this.
Depends on: 697132
Non-fullscreen HTML5 video should also stop the screensaver. https://developer.apple.com/library/mac/#qa/qa1160/_index.html
(In reply to Reuben Morais [:reuben] from comment #14) > https://developer.apple.com/library/mac/#qa/qa1160/_index.html I think that article is outdated; the modern way of preventing sleep on Mac is documented here: https://developer.apple.com/library/mac/#releasenotes/Darwin/RN-IOKitPowerManagment/_index.html#//apple_ref/doc/uid/TP40006501-CH1-DontLinkElementID_4 and here: https://developer.apple.com/library/mac/#qa/qa1340/_index.html
(In reply to Markus Stange from comment #15) I was thinking we'd just use whatever API was implemented in bug 697132 to implement this feature.
Some docs on Windows: * Why does Windows wait longer than my screen saver idle timeout before starting the screen saver? http://blogs.msdn.com/b/oldnewthing/archive/2009/08/20/9876113.aspx * Block screensaver/standby/energy management http://social.msdn.microsoft.com/forums/en-US/Vsexpressvcs/thread/80704e31-ea1e-4d5f-bab2-3ba4d910b363 NB: If password protection is enabled by policy, the screen saver is started regardless of what an application does with the SC_SCREENSAVE notification—even if fails to pass it to DefWindowProc.
(In reply to Chris Pearce (:cpearce) from comment #16) > (In reply to Markus Stange from comment #15) > > I was thinking we'd just use whatever API was implemented in bug 697132 to > implement this feature. It would be a good idea to use this API indeed but it has no backend for other OS than B2G so the backends will have to be written anyway.
Something like the Linux .sh script here would be nice, but for Windows: http://www.webupd8.org/2012/05/2-ways-to-temporarily-disable.html
The way to do this on Mac OS X is UpdateSystemActivity. http://stackoverflow.com/questions/1324814/what-is-the-cocoa-equivalent-of-updatesystemactivity
The linux solution to stopping the screensaver from starting is to be done using d-bus: http://people.gnome.org/~mccann/gnome-screensaver/docs/gnome-screensaver.html#gs-method-Inhibit
confirmed on android (ff17)
More and more video playback is now HTML5-based, and with all the effort to get rid of 3rd party plugins (also Flash), this would be a serious UX improvement. I uninstalled Flash and the screensaver is sometimes driving me nuts on YouTube. Dummy keystrokes every 55s (see comment #10) sounds like an elegant cross-platform solution, no? As this is open since 2009... time to take action? :-) Could any1 take this up?
(In reply to Carsten from comment #26) > Dummy keystrokes every 55s (see comment #10) sounds like an elegant > cross-platform solution, no? > As this is open since 2009... time to take action? :-) Could any1 take this > up? I think this is too much of a ad-hoc solution. It is easy to implement especially for cross-platform but it isn't too difficult to implement this along with html5 video. http://msdn.microsoft.com/en-us/library/cc144066%28v=vs.85%29.aspx Better done right IMO !? But definitely needs a bump. I have shifted back to flash plugins since I had this issue. Haven't gone back..
We should disable the screen save for non-fullscreen playback too.
Summary: Fullscreen video should disable screensaver during playback → Video should disable screensaver during playback
(In reply to comment #28) > We should disable the screen save for non-fullscreen playback too. Why? Some websites use <video> as an element in their design these days (for example, as the page background.) It seems counter intuitive for such a website to disable the screen saver!
We already use the power manager service to create a "screen" wake lock to disable the screen saver in HTMLVideoElement::WakeLockUpdate(), but the wake lock listener that actually disables the screen saver is only implemented for B2G and I think Android, but not on other platforms. I have a patch in Bug 968603 to implement a wake lock listener on Windows, so we'll disable the screensaver on Windows during video playback. To fix this on other platforms, we'll need to add wake lock listeners for them too. I suggest we use this bug to track when support for Mac, Linux, and Windows (and Android if it hasn't already) have all landed.
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailacopolypse) from comment #29) > (In reply to comment #28) > > We should disable the screen save for non-fullscreen playback too. > > Why? Some websites use <video> as an element in their design these days > (for example, as the page background.) It seems counter intuitive for such > a website to disable the screen saver! Because sometimes you want to watch a video non-fullscreen with duration longer than your screensaver's timeout? I certainly don't fullscreen all the videos I watch. I think it would be hard to programmatically distinguish between the non fullscreen foreground case and all permutations of the video-as-page-background use case you describe.
(In reply to comment #31) > (In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, > emailacopolypse) from comment #29) > > (In reply to comment #28) > > > We should disable the screen save for non-fullscreen playback too. > > > > Why? Some websites use <video> as an element in their design these days > > (for example, as the page background.) It seems counter intuitive for such > > a website to disable the screen saver! > > Because sometimes you want to watch a video non-fullscreen with duration longer > than your screensaver's timeout? I certainly don't fullscreen all the videos I > watch. > > I think it would be hard to programmatically distinguish between the non > fullscreen foreground case and all permutations of the video-as-page-background > use case you describe. Can we at least do that for videos which have started playback as a result of a user action?
> Can we at least do that for videos which have started playback as a result > of a user action? Agreed. I logged on to suggest just that but you beat me to it.
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailacopolypse) from comment #32) > Can we at least do that for videos which have started playback as a result > of a user action? Sure, that sounds like a good idea. Reasonable even. We may need to wait for bug 966493 to be fixed first, otherwise nsEventStateManager::IsHandlingUserInput() won't count touch events as user generated, and we may regress disabling the screensaver on B2G.
There is workaround for people trying to find a permanent fix (like I do). The program called HOT CORNERS works on both WinXP and Win7 (I guess nobody is using Win8, at least the ones that know anything). You set lower left corner (for example) as screensaver disabled and it doesn't start.
The fix for this will ship on Windows in Firefox 30. Other platforms hopefully will make by Firefox 30 or soon after.
I agree with the importance of landing this fix since and so lets go ahead and track this.
meanwhile, workaround: media.ogg.enabled;false media.opus.enabled;false media.raw.enabled;false media.webm.enabled;false media.windows-media-foundation.enabled;false media.directshow.enabled;false media.navigator.enabled;false media.autoplay.enabled;false media.windows-media-foundation.play-stand-alone;false media.windows-media-foundation.use-dxva;false media.peerconnection.enabled;false media.wave.enabled;false most players then fall back to Flash, and since FF currently is no media player because of this bug, its the best thing one can do ....
I discussed this issue with the desktop team (Chad, Madhava, Gavin). This is not a high priority for them right now. As such, dropping the tracking flag. From comment 36 I take it that this has already been fixed on Windows in another bug. (Bug ref?) If that is correct, are there other follow up bugs for the other platforms? Is there work to do in this bug?
(In reply to Lawrence Mandel [:lmandel] from comment #40) > I discussed this issue with the desktop team (Chad, Madhava, Gavin). This is > not a high priority for them right now. As such, dropping the tracking flag. > > From comment 36 I take it that this has already been fixed on Windows in > another bug. (Bug ref?) Windows: bug 968603. > If that is correct, are there other follow up bugs > for the other platforms? Is there work to do in this bug? Linux: bug 811261 B2G: Already fixed by some unknown bug MacOSX: Bug 772347 Android: fixed in bug 739542
Until Firefox 30 is available I am using Caffeine http://zhornsoftware.co.uk/caffeine
> Can we at least do that for videos which have started playback as a result > of a user action? Chrome has something similar on Android: it doesn't load/play audio (maybe video as well) on cellular connection unless it's user initiated action so autoplay/event from onload don't work. But I'm not sure if that's the best and only solution. Isn't the largest amount of videos on various video sites (like youtube) that start playback automatically? How about additional condition: Non-fullscreen autoplayed videos without loop which also output audio. IMHO video ads usually do not start playing sound and interactive websites often use video loops.
> IMHO video ads usually do not start playing sound By your own admission (and now mine) this is not reliable. I have seen it happen enough that they DO start playing sound, that I DONT want that to be part of any algorithm.
Starting with Firefox 30 this issue has been fixed. My test results Playing Screen stays on Paused Screen turns off Other tab playing Screen turns off
Not on my setup (Arch 64, Nightly 33.0a1). This bug is about fullscreen playing, right?
> The fix for this will ship on Windows in Firefox 30. Other platforms hopefully will make by Firefox 30 or > soon after.
Oh, it seems I missed that one…
All the dependent bugs are fixed. I think we can close this one.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I'm using FF 34.0.5-1 on ArchLinux and I still experience this problem. Is this fix supposed to be there?
I have the same problem with html5 videos on 34.0.5. Perhaps the fix is in aurora?
I assume you both are seeing bug 797625?
In my case it doesn't matter if it's fullscreen or not, so it's not bug 797625.
(In reply to Oleg from comment #51) > I'm using FF 34.0.5-1 on ArchLinux and I still experience this problem. > Is this fix supposed to be there? Linux support was bug 811261 which should be in FF 33 and later. Are you using a GDK-based desktop environment? Is dbus running? The relevant code is http://dxr.mozilla.org/mozilla-central/source/widget/gtk/WakeLockListener.cpp
(In reply to Ralph Giles (:rillian) from comment #55) > Linux support was bug 811261 which should be in FF 33 and later. Are you > using a GDK-based desktop environment? Is dbus running? The relevant code is > http://dxr.mozilla.org/mozilla-central/source/widget/gtk/WakeLockListener.cpp I'm using KDE 4.14 and dbus is running. Do I need to switch to GNOME or the likes for this to work?
(In reply to Aloysius from comment #56) > I'm using KDE 4.14 and dbus is running. > Do I need to switch to GNOME or the likes for this to work? No. It was meant to work with KDE. Are you able to file a new bug, blocking this one, please, with output produced from dbus-monitor while starting the video?
I'm on Ubuntu 14.10 using Firefox Nightlies and can confirm that the machine will still lock itself when playing flash videos.
(In reply to Karl Tomlinson (:karlt) from comment #57) > No. It was meant to work with KDE. > Are you able to file a new bug, blocking this one, please, with output > produced from dbus-monitor while starting the video? For some reason I can't reproduce the bug anymore. I will get back to you if the problem shows up again. (In reply to Paul [pwd] from comment #58) > I'm on Ubuntu 14.10 using Firefox Nightlies and can confirm that the machine > will still lock itself when playing flash videos. I think flash videos are outside the scope of this fix. You might want to install lightsOn to address that.
all add-ons are disabled but only in safe-mode problem Resolves
5 years ago
You need to log in before you can comment on or make changes to this bug.