Web interface: prevent screen saver from activating #99436

New Issue

Sybren A. Stüvel · 2022-07-04T16:09:51+02:00

Sybren A. Stüvel commented

2022-07-04 16:09:51 +02:00

The web interface should (optionally?) prevent screensavers from activating.

This is most relevant for the Last Rendered view, for displaying in a central location in an animation studio.

The web interface should (optionally?) prevent screensavers from activating. This is most relevant for the Last Rendered view, for displaying in a central location in an animation studio.

Sybren A. Stüvel commented

2022-07-04 16:09:51 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Sybren A. Stüvel commented

2022-07-04 16:09:51 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel added

and removed

labels 2023-02-17 11:12:46 +01:00

Gangneron commented

2023-09-23 11:57:27 +02:00

Hello, could you tell me exactly what you expect from the changes to the web interface.
Thanks in advance

Hello, could you tell me exactly what you expect from the changes to the web interface. Thanks in advance

Sybren A. Stüvel commented

2023-09-26 10:43:34 +02:00

The goal of this task is to make it possible for a computer to show the Flamenco dashboard, without any further supervision. It would be great if Flamenco itself had a way to keep the screensaver from activating. Not sure if this is even possible, though.

Sybren A. Stüvel added

and removed

labels 2023-09-26 10:43:42 +02:00

Mateus Abelli commented

2024-05-09 02:34:16 +02:00

I did some research and it looks like there are a couple ways to fix this:

Using Screen Wake Lock API, as it supports all major browsers, except Firefox.
Playing an invisible video on loop --- not pretty hack for Firefox, otherwise setting the flag dom.screenwakelock.enabled to true.

Alternatively, we can achieve the best of both worlds with NoSleep.js as it has a fallback with the second option for browsers that don't support the API yet. See the demo.

I did some research and it looks like there are a couple ways to fix this: - Using [Screen Wake Lock API](https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API), as it [supports](https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API#browser_compatibility) all major browsers, except Firefox. - Playing an invisible video on loop --- not pretty hack for Firefox, otherwise [setting](https://support.mozilla.org/en-US/kb/about-config-editor-firefox) the flag `dom.screenwakelock.enabled` to `true`. Alternatively, we can achieve the best of both worlds with [NoSleep.js](https://github.com/richtr/NoSleep.js) as it has a fallback with the second option for browsers that don't support the API yet. See the [demo](https://nosleep.page/).

Sybren A. Stüvel commented

2024-05-10 17:11:19 +02:00

The Screen Wake Lock API is not available, unfortunately. From MDN:

Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

This means that it's only functional when Flamenco is running behind a TLS connection. As Flamenco is designed to run on-premise, by not-too-technical people, it's unlikely that this will be the case.

So I guess playing a video is the only option here.

The Screen Wake Lock API is not available, unfortunately. From [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API): > Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers. This means that it's only functional when Flamenco is running behind a TLS connection. As Flamenco is designed to run on-premise, by not-too-technical people, it's unlikely that this will be the case. So I guess playing a video is the only option here.

👍 1

Mateus Abelli commented

2024-05-11 03:03:21 +02:00

When reading more about Secure contexts I was glad that it considered locally deployed pages as secure.

Locally-delivered resources such as those with http://127.0.0.1 URLs, http://localhost and http://*.localhost URLs (e.g. http://dev.whatever.localhost/), and file:// URLs are also considered to have been delivered securely.

And then disappointed because it only considers those from "localhost" not the ones under a local IP address such as 192.168.0.16

About the playing video option, I developed a tiny proof of concept using Vue and some other libs that our webapp uses too such as pinia for state management. I have tested and it seems to be working as expected in both Chromium based browsers and Firefox.

When reading more about [Secure contexts](https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts) I was glad that it considered locally deployed pages as secure. > Locally-delivered resources such as those with http://127.0.0.1 URLs, http://localhost and http://*.localhost URLs (e.g. http://dev.whatever.localhost/), and file:// URLs are also considered to have been delivered securely. And then disappointed because it only considers those from "localhost" not the ones under a local IP address such as 192.168.0.16 About the playing video option, I developed a tiny [proof of concept ](https://github.com/playsrc/frontend-wakelock-poc) using Vue and some other libs that our webapp uses too such as pinia for state management. I have tested and it seems to be working as expected in both Chromium based browsers and Firefox.

Sybren A. Stüvel commented

2024-05-15 10:04:17 +02:00

About the playing video option, I developed a tiny proof of concept using Vue and some other libs that our webapp uses too such as pinia for state management. I have tested and it seems to be working as expected in both Chromium based browsers and Firefox.

Nice!

Do you know how dependent this is on things like the video size, presence of an audio track, whether the video is actually visible (or hidden via CSS), etc?

I've used FFmpeg to turn your one-second-video.mp4 into a 16x16 pixel one-second-video.webm. This not just reduces the screen size, but also turns your huge monstrosity (15 kB) into something slightly more manageable (2 kB) 😸

The reason I ask is that I would suspect there's limits to this, where browsers have a different interpretation of what the user is doing with the video, from "watching a video" to "some advertisement in a corner".

> About the playing video option, I developed a tiny [proof of concept ](https://github.com/playsrc/frontend-wakelock-poc) using Vue and some other libs that our webapp uses too such as pinia for state management. I have tested and it seems to be working as expected in both Chromium based browsers and Firefox. Nice! Do you know how dependent this is on things like the video size, presence of an audio track, whether the video is actually visible (or hidden via CSS), etc? I've used FFmpeg to turn your [`one-second-video.mp4`](https://github.com/playsrc/frontend-wakelock-poc/blob/main/public/one-second-video.mp4) into a 16x16 pixel [`one-second-video.webm`](/attachments/8c5516ec-d399-4ba7-abe3-76e9f05e5c8a). This not just reduces the screen size, but also turns your huge monstrosity (15 kB) into something slightly more manageable (2 kB) 😸 The reason I ask is that I would suspect there's limits to this, where browsers have a different interpretation of what the user is doing with the video, from "watching a video" to "some advertisement in a corner".

one-second-video.webm

2.0 KiB

Mateus Abelli commented

2024-05-16 02:06:12 +02:00

Hi @dr.sybren I did a few more tests.

Do you know how dependent this is on things like the video size

Your 16x16 webm version worked, so I went further and set the <video width="1" height="1" /> and it also worked. Apparently the browser doesn't care a lot about the video size (which is a bit weird how a 1px can wake lock your computer 😄)

presence of an audio track

So far on tests it worked with the muted audio track of the video, not sure if it even has an audio track, if one is present it should be muted because of autoplay. If for any reason autoplay doesn't work then some awful JS glue would be required to play on the toggle switch.

whether the video is actually visible (or hidden via CSS)

After doing some extreme tests such as 1px video with absolute position at -500px I decided to completely hide it already simply with display: none and surprisingly it also worked 😆

I have updated the POC repo with the changes and made it more convenient for you to try it out by publishing to gh pages. Check out the live version.

Hi @dr.sybren I did a few more tests. > Do you know how dependent this is on things like the video size Your 16x16 webm version worked, so I went further and set the `<video width="1" height="1" />` and it also worked. Apparently the browser doesn't care a lot about the video size (which is a bit weird how a 1px can wake lock your computer 😄) > presence of an audio track So far on tests it worked with the muted audio track of the video, not sure if it even has an audio track, if one is present it should be muted because of [autoplay](https://www.w3schools.com/tags/att_video_autoplay.asp). If for any reason autoplay doesn't work then some awful JS glue would be required to play on the toggle switch. > whether the video is actually visible (or hidden via CSS) After doing some extreme tests such as 1px video with absolute position at -500px I decided to completely hide it already simply with `display: none` and surprisingly it also worked 😆 I have updated the POC [repo](https://github.com/playsrc/frontend-wakelock-poc) with the changes and made it more convenient for you to try it out by publishing to gh pages. Check out the [live version](https://playsrc.github.io/frontend-wakelock-poc/).

Sybren A. Stüvel commented

2024-05-16 08:35:16 +02:00

Your 16x16 webm version worked, so I went further and set the <video width="1" height="1" /> and it also worked. Apparently the browser doesn't care a lot about the video size (which is a bit weird how a 1px can wake lock your computer 😄)

👍

So far on tests it worked with the muted audio track of the video, not sure if it even has an audio track

ffprobe is your friend:

$ ffprobe.exe one-second-video.webm 
ffprobe version 7.0-full_build-www.gyan.dev Copyright (c) 2007-2024 the FFmpeg developers
[...]
Input #0, matroska,webm, from 'one-second-video.webm':
  Metadata: [...]
  Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv, bt709, progressive), 16x16, SAR 21:16 DAR 21:16, 29.97 fps, 29.97 tbr, 1k tbn (default)
      Metadata: [...]
  Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp (default)
      Metadata: [...]

if one is present it should be muted because of autoplay. If for any reason autoplay doesn't work then some awful JS glue would be required to play on the toggle switch.

I think that's a good idea to do anyway, because my browser (Firefox) by default disallows any auto-play. Unless explicitly allowed for that website, of course. This may also be an issue if we want the webapp to remember whether it was wakelocked or not.

After doing some extreme tests such as 1px video with absolute position at -500px I decided to completely hide it already simply with display: none and surprisingly it also worked 😆

Woah!

Which browser & OS did you test with?

I have updated the POC repo with the changes and made it more convenient for you to try it out by publishing to gh pages. Check out the live version.

I'll give it a try when I have the time to let my computer sit still ;-)

> Your 16x16 webm version worked, so I went further and set the `<video width="1" height="1" />` and it also worked. Apparently the browser doesn't care a lot about the video size (which is a bit weird how a 1px can wake lock your computer 😄) :+1: > So far on tests it worked with the muted audio track of the video, not sure if it even has an audio track `ffprobe` is your friend: ``` $ ffprobe.exe one-second-video.webm ffprobe version 7.0-full_build-www.gyan.dev Copyright (c) 2007-2024 the FFmpeg developers [...] Input #0, matroska,webm, from 'one-second-video.webm': Metadata: [...] Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv, bt709, progressive), 16x16, SAR 21:16 DAR 21:16, 29.97 fps, 29.97 tbr, 1k tbn (default) Metadata: [...] Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp (default) Metadata: [...] ``` > if one is present it should be muted because of [autoplay](https://www.w3schools.com/tags/att_video_autoplay.asp). If for any reason autoplay doesn't work then some awful JS glue would be required to play on the toggle switch. I think that's a good idea to do anyway, because my browser (Firefox) by default disallows any auto-play. Unless explicitly allowed for that website, of course. This may also be an issue if we want the webapp to remember whether it was wakelocked or not. > After doing some extreme tests such as 1px video with absolute position at -500px I decided to completely hide it already simply with `display: none` and surprisingly it also worked 😆 Woah! Which browser & OS did you test with? > I have updated the POC [repo](https://github.com/playsrc/frontend-wakelock-poc) with the changes and made it more convenient for you to try it out by publishing to gh pages. Check out the [live version](https://playsrc.github.io/frontend-wakelock-poc/). I'll give it a try when I have the time to let my computer sit still ;-)

Mateus Abelli commented

2024-05-16 13:53:06 +02:00

ffprobe is your friend:

Thanks for the ffprobe tip! 👍

I think that's a good idea to do anyway, because my browser (Firefox) by default disallows any auto-play. Unless explicitly allowed for that website, of course. This may also be an issue if we want the webapp to remember whether it was wakelocked or not.

I tried to set my Firefox on Windows to deny autoplay but the poc website worked anyway. It did not seem to respect my setting. I'll be trying some js glue for events where autoplay will not work, so far it's being too magical for me, I'm suspicious of why this is working.

Which browser & OS did you test with?

Previously tested in firefox and brave (both snaps) on ubuntu, and chrome, edge and firefox on windows.

> ffprobe is your friend: Thanks for the ffprobe tip! 👍 > I think that's a good idea to do anyway, because my browser (Firefox) by default disallows any auto-play. Unless explicitly allowed for that website, of course. This may also be an issue if we want the webapp to remember whether it was wakelocked or not. I tried to set my Firefox on Windows to deny autoplay but the poc website worked anyway. It did not seem to respect my setting. I'll be trying some js glue for events where autoplay will not work, so far it's being too magical for me, I'm suspicious of why this is working. > Which browser & OS did you test with? Previously tested in firefox and brave (both snaps) on ubuntu, and chrome, edge and firefox on windows.

Sign in to join this conversation.