screensaver starts while playing HTML5 videos

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!

Ubuntu bug:
https://bugs.edge.launchpad.net/firefox/+bug/434476

*** Bug 565762 has been marked as a duplicate of this bug. ***

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.

*** Bug 696563 has been marked as a duplicate of this bug. ***

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.

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.

*** Bug 745546 has been marked as a duplicate of this bug. ***

*** Bug 745519 has been marked as a duplicate of this bug. ***

(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.

*** Bug 772347 has been marked as a duplicate of this bug. ***

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?

Because opinions differ. ;)

We also want non-fullscreen video and webrtc chats to disable the screensaver. I, for one, find it very annoying when I'm watching a non-fullscreen video and the screensaver kicks in.

FYI, there's code in HTMLMediaElement to ensure the screensaver is only disabled when the video is actually in a visible region of the webpage, in a foreground tab.

The screensaver should not be inhibited by "cpu" and "high-priority" wake locks. It looks like those are used to inhibit GC or disable power save (see Bug 872430).

I've found two screen related wake locks - "DOM_Fullscreen" (Bug 805017) and "screen" (Bug 868325). I think any element which wants to inhibit screensaver should create the "screen" or "DOM_Fullscreen" wake locks - like the VideoElement does.

Created attachment 8441363
patch v.4

I watches "DOM_Fullscreen" and "screen" wakelocks only.

Passes the broken test:
./mach mochitest-plain dom/browser-element/mochitest/priority

Comment on attachment 8441363
patch v.4

Try build: https://tbpl.mozilla.org/?tree=Try&rev=e2e2ba6d85b8

Comment on attachment 8441363
patch v.4

The "screen" wake lock sounds good.
I suspect we shouldn't need DOM_Fullscreen, but I'm happy to let that by because other platforms treat that similarly.

However, we now know that the "Screensaver is already inhibited" assertion can fail, so that needs to be changed to an early return.

(In reply to Martin Stránský from comment #53)
> The screensaver should not be inhibited by "cpu" and "high-priority" wake
> locks. It looks like those are used to inhibit GC or disable power save (see
> Bug 872430).

This isn't an issue with wake lock code, it's an issue with wake locks being used incorrectly on desktop. The better solution here would be to make sure that "cpu" and "high-priority" are never used in the first place, on desktop.

(In reply to Martin Stránský from comment #54)
> Passes the broken test:
> ./mach mochitest-plain dom/browser-element/mochitest/priority

...by ignoring those topic strings outright. It doesn't fix the actual problem.

We want to inhibit the screensaver when video is playing, not when *fullscreen* video is playing. It looks like the patch above is trying to only inhibit the screensaver for fullscreen video.

(In reply to Chris Pearce (:cpearce) from comment #58)
> We want to inhibit the screensaver when video is playing,

I assume the "screen" wake lock is meant to take care of that.
http://hg.mozilla.org/mozilla-central/annotate/37f08ddaea48/content/html/content/src/HTMLVideoElement.cpp#l312

(In reply to Edwin Flores [:eflores] [:edwin] from comment #57)
> (In reply to Martin Stránský from comment #53)
> > The screensaver should not be inhibited by "cpu" and "high-priority" wake
> > locks. It looks like those are used to inhibit GC or disable power save (see
> > Bug 872430).
>
> This isn't an issue with wake lock code, it's an issue with wake locks being
> used incorrectly on desktop. The better solution here would be to make sure
> that "cpu" and "high-priority" are never used in the first place, on desktop.

That's possible but we just can't disable screensaver for *any* lock, right? We want to disable it for the screen-related events only, not for audio events or so.

I see the "DOM_Fullscreen" should not be used here - It seems to be set for any fullscreen elements, like full-screen webgl canvas, full-screen browsing and so.

I think you want the "screen" topic, and the "locked-foreground" state to denote when to disable the screen saver.

HTMLMediaElement should already manage only disabling the screen saver when media is playing and in a foreground tab, and bug 1022669 is being worked on right now to ensure that we don't take a screen wake lock for audio-only media.

Edwin's point is that we shouldn't be taking non-screen wakelocks on desktop, they're meant for battery constrained mobile devices; for example the "cpu" wakelock code in HTMLMediaElement.cpp should really be behind b2g and android include guards.

This can be simplified considerably given we need only listen for the "screen" lock.
The hash table is not necessary, and classes can probably be merged.

Created attachment 8442071
patch v.5

Something like that? It listens to "screen" locks only and returns when screensaver is already inhibited.

Comment on attachment 8442071
patch v.5

This could be much simpler, but let's not hold off this feature any longer.
Tidying up can be a followup.

Comment on attachment 8442071
patch v.5

Try: https://tbpl.mozilla.org/?tree=Try&rev=ae11997b18f8

https://hg.mozilla.org/integration/mozilla-inbound/rev/38476bd45285

https://hg.mozilla.org/mozilla-central/rev/38476bd45285

Great!

I've tested this using Ubuntu 14.04 x64 and FF 33d.0b1(BUild Id: 20140903133924).

The turn screen off enters on the set time(Ubuntu 14.04 doesn’t ship with any screen savers, just a black screen that appears when your system is idle) when playing a youtube video on fullscreen. The same is happening when playing a video without going to fullscreen. I even installed XScreenSaver to see if the issue is reproducible using it instead of gnome screensaver and it is reproducible with XScreenSaver.

Is the fix not suppose to work for the turning off screen feature from Ubuntu? or is this an issue with the fix?

So this does not appear to work on Ubuntu and Fedora. Can anyone shed some light on the test results from comment 69 and what is actually expected here? Otherwise we'll just have to reopen this as it does not seem to do anything.

It works for me with gnome-screensaver 2.30, firefox nightly 2014-08-30, both with and without fullscreen. Sometimes screensaver stiil appears after ~ 25 minutes of video (but it's configured to get activated after 2 minutes), so it's another problem.

The patch utilizes the org.freedesktop.ScreenSaver or org.gnome.SessionManager D-BUS interfaces so it depends if you have such services enabled or not and if your screen saver listen here.

Check d-feet (#yum install d-feet.noarch in Fedora) to inspect your active dbus interfaces.

For instance I see only "org.mate.ScreenSaver" interface on Fedora20/MATE desktop. So the problem may be here.

On Ubuntu 14.04 I have org.gnome.SessionManager but the screensaver still enters.
Based on previous comments it appears that the fix is working for gnome-screensaver 2.30 but that version of gnome-screensaver is pretty old( from September 2010). It appears that the fix is not working for Gnome 3. I found a post that discusses the changes suffered by Gnome lock-screen with the 3.0 release, not sure how relevant is to this bug but I'm going to post it nevertheless. http://www.lucidelectricdreams.com/2011/06/disabling-screensaverlock-screen-on.html

Our testing machines are running only newer versions of Ubuntu and no other Linux based operating systems so our verification of this bug options are limited. We can only confirm that the fix is not working on the newer Ubuntu releases.

Removing "qe-verify+" since it seems we cannot verify this.

Doesn't seem to be fixed in Firefox 33 on OpenSuse 13.1 with KDE4 & XScreenSaver-5.29 (not KDE's one): xscreensaver still sprungs up while playing fullscreen video on Youtube. May be a result of using "Download Manager (S3)" addon which draws a bar at the bottom that disappear slightly after video goes fullscreen. One more reason why it should work on non-fullscreen videos also, since the definition of "fullscreen" seems ambiguous.

Also, how about inhibiting screensaver on flash plugin spawn and uninhibiting on its termination ? Adobe will never add this functionality, but we are stuck with it. Doing so in Firefox as extension of this patch looks like the most straightforward solution. Especially in comparison to something like https://github.com/iye/lightsOn

Sergey, could you check whether with the S3 add-on disabled the screensaver is still not inhibited?

(In reply to Milan Bouchet-Valat from comment #78)
> Sergey, could you check whether with the S3 add-on disabled the screensaver
> is still not inhibited?

It's that way even with almost empty profile and "safe mode". I also noticed that VLC-2.1.5 doesn't inhibit it also even thought it supposedly got dbus xscreensaver interface support (https://trac.videolan.org/vlc/ticket/4739). Upgrading to xscreensaver-5.30 didn't help either. Not sure what's going on.

(In reply to Sergey Kondakov from comment #79)
> (In reply to Milan Bouchet-Valat from comment #78)
> > Sergey, could you check whether with the S3 add-on disabled the screensaver
> > is still not inhibited?
>
> It's that way even with almost empty profile and "safe mode". I also noticed
> that VLC-2.1.5 doesn't inhibit it also even thought it supposedly got dbus
> xscreensaver interface support (https://trac.videolan.org/vlc/ticket/4739).

It's not "dbus xscreensaver interface support". It has nothing to do with XScreensaver.

> Upgrading to xscreensaver-5.30 didn't help either. Not sure what's going on.

XScreensaver implements no D-Bus interface. The D-Bus interface should work in GNOME and KDE though.

(In reply to Bastien Nocera from comment #80)
> It's not "dbus xscreensaver interface support". It has nothing to do with
> XScreensaver.

Ah, just noticed ancient https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377056

> XScreensaver implements no D-Bus interface. The D-Bus interface should work
> in GNOME and KDE though.

For some reason i thought that XSS not only had it, but also was the first one to implement it. But it seems that its developer isn't too keen on this new "kit & bus" fashion.
So now one has to use those abominations just to have a screensaver ? Then `xdg-screensaver` abstraction should have, probably, been used instead of direct dbus calls. It supports both dbus and console commands.

Otherwise https://launchpad.net/caffeine shim is the only cross-DE option, it seems.

(In reply to Sergey Kondakov from comment #81)
> So now one has to use those abominations just to have a screensaver ? Then
> `xdg-screensaver` abstraction should have, probably, been used instead of
> direct dbus calls. It supports both dbus and console commands.
>
> Otherwise https://launchpad.net/caffeine shim is the only cross-DE option,
> it seems.

I doubt that anyone is going to have time to work on it. You've already looked up the details so the next step for you is creating a bug for the new change and providing a patch. :-)

I'll add that xdg-screensaver is an unmitigated piece of crap. It reimplements the bugs that using D-Bus for inhibition is supposed to fix (namely that if the app disappears, the screensaver shouldn't be left inhibited).

You could add D-Bus support to xscreensaver without linking to a D-Bus implementation. Look at the SDL2 code, it implements the same inhibition mechanism that Firefox and VLC implement through a dlopen()'ed libdbus.so.

However, I would recommend that you use a modern screensaver if you expect modern features.

Is that supposed to work when watching a fullscreen Flash video, like Youtube? It doesn't here on Fedora 20 with Firefox 33 (and the D-Bus interface is present).

(In reply to Milan Bouchet-Valat from comment #84)
> Is that supposed to work when watching a fullscreen Flash video, like
> Youtube? It doesn't here on Fedora 20 with Firefox 33 (and the D-Bus
> interface is present).

No.

(In reply to Bastien Nocera from comment #83)
> I'll add that xdg-screensaver is an unmitigated piece of ****. It
> reimplements the bugs that using D-Bus for inhibition is supposed to fix
> (namely that if the app disappears, the screensaver shouldn't be left
> inhibited).

Mh, yeah, it's odd that it still doesn't do something like periodically checking that calling app is still alive.

> You could add D-Bus support to xscreensaver without linking to a D-Bus
> implementation. Look at the SDL2 code, it implements the same inhibition
> mechanism that Firefox and VLC implement through a dlopen()'ed libdbus.so.

If so, it probably should be at least communicated to the XSS author. But he doesn't seem to give much shits about Linux & X these days, ironically (http://www.jwz.org/xscreensaver/faq.html).

> However, I would recommend that you use a modern screensaver if you expect
> modern features.

It would be nice, except:
1) KDE screensaver doesn't seem to be even coming as separate binary, let alone DE-independent one. At one point KDE devs even tried to completely remove it and forcibly replace with their NIH plasma locking (http://ostatic.com/blog/kde-to-say-buh-bye-to-screensavers). The thing still draws plasma lock screen (which supposed to be disabled) and only few seconds after the screensaver above it. And they don't give a damn.
2) GNOME screensaver requires the core GNOME framework to go with it, not just GTK. Kinda overkill for a screensaver.

And i don't exactly expect "modern features". I expect _Firefox to inhibit/suspend a screensaver when it draws a video. Any videos and any screensavers_.

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #85)
> (In reply to Milan Bouchet-Valat from comment #84)
> > Is that supposed to work when watching a fullscreen Flash video, like
> > Youtube? It doesn't here on Fedora 20 with Firefox 33 (and the D-Bus
> > interface is present).
>
> No.

Which makes whole thing pretty much useless. It should:
1) Work with any unpaused (like mplayer does) HTML5 video, fullscreen or not.
Time to put that famous "platform-independent" video abstraction (from gstreamer, proprietary renderers and etc.) code, that makes video scaling, pausing and any interaction to be laggy as hell (even laggier than flash) on any machine, to good use of detecting paused state.
2) Work on flash spawn.
3) Work with any screensaver.
I hate to say it, but maybe such disparity warrants a dirty "Windows-way" of simulating user activity periodically while video is playing. Examples of this probably can be found in KDE/GNOME code that creates dbus "SimulateUserActivity" "method" or in Firefox's code itself.

Moreover, aforementioned "Caffeine" Ubuntu hack is pretty crude (it supposed to somehow force screensavers off when detecting a fullscreen window). It didn't seem to work for me with HTML5 video in Firefox. And going for fullscreen windows is a questionable approach anyway.

(In reply to Sergey Kondakov from comment #86)
> 2) GNOME screensaver requires the core GNOME framework to go with it, not
> just GTK. Kinda overkill for a screensaver.
Scratch that ! I just read up on:
http://www.jwz.org/blog/2011/10/has-gnome-3-decided-that-people-shouldnt-want-screen-savers/ (from XSS author)
https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-screensaver (Ubuntu fix plan that gone nowhere)
https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/994612 (report about complete uselessness of GNOME SS)

Long story short:
Gnome gone Reverse-Xzibit and removed screensaver out of... their screensaver. Which locks the screen... but HAS NOT SCREENSAVERS.

> Which makes whole thing pretty much useless.
Even more than i imagined and complained previously.
> Moreover, aforementioned "Caffeine" Ubuntu hack is pretty crude...
Looks like in non-obsolete versions they removed XSS support... if it even worked. Which makes it also not an option.
> And i don't exactly expect "modern features". I expect _Firefox to
> inhibit/suspend a screensaver when it draws a video. Any videos and any
> screensavers_.
All of that above makes XSS The Only Option of having actual screensavers under X (except using KDE SS BUT ONLY under KDE session, because it's not even a binary).
And for that to work either:
1) FF devs must play nice with XSS
2) XSS dev should be persuaded to provide dbus interface as dbus today is the cross-DE daemon interface
3) XSS could be forked by a hacker who's not afraid of dbus

In any case this bug cannot be closed as "FIXED" because actual screesaver is not getting disabled under Linux, only lockers are.

Hi, i can see this is marked as fixed but i can confirm that on latest xubuntu and latest debian testing, firefox 35.01 is not able to disable screensaver or screen power management.

(In reply to electrovalent from comment #88)
> Hi, i can see this is marked as fixed but i can confirm that on latest
> xubuntu and latest debian testing, firefox 35.01 is not able to disable
> screensaver or screen power management.

Ditto. I just reinstalled Ubuntu Studio 14.04 and installed Unity, and in Firefox 35.0.1 it's not disabling the screensaver during playback.