Add wakelock support #1984

tsukasa-au · 2025-08-26T06:48:00Z

Add a new configuration option use_wakelock to allow noVNC to stop the local display from going to sleep. This is especially useful with view-only sessions.

We only hold the view lock while connected to a server. We will also attempt to reacquire the wakelock if we lost it due to a visibility change (the tab becoming inactive, or during the transition into/from fullscreen).

All existing unittests have been run (with #1983 manually patched into my working directory), and the change has been manually tested in Firefox 142.

CendioZeijlon · 2025-08-28T13:34:15Z

There could absolutely be cases where this can be useful, but we can't assume that all users want to prevent their screen from locking when they are connected to a session.

It should probably be an opt-in feature.

tsukasa-au · 2025-08-29T02:14:34Z

It should probably be an opt-in feature.

100% agree.

This feature is controlled by the newly added use_wakelock option. The default value of this option is false.

If you want, I can try to plumb this configuration option into the (advanced) settings in the UI. This would also require me to add support for toggling the configuration at runtime.

CendioZeijlon · 2025-08-29T06:49:50Z

If you want, I can try to plumb this configuration option into the (advanced) settings in the UI. This would also require me to add support for toggling the configuration at runtime.

That sounds great! 😃

CendioZeijlon · 2025-09-10T08:43:53Z

How are you progressing on this? 🙂

tsukasa-au · 2025-09-12T00:41:25Z

Thanks for checking up on this.

I have rewritten this, but am currently working on tests. I am at a conference this/next week, but will try to get the tests finished after that.

I have pushed my new changes to this PR, but I want to clean them up a little:

add documentation for the new WakeLockManager class.
add a couple more tests
moving the test-related code into the test commit (the event related code, that allows the tests to track the state machine transitions).
move the list of valid state transitions into the test.

tsukasa-au · 2025-09-12T07:52:08Z

Actually... I ended up finding some time to hack on the last few things I wanted with this. I have updated this PR.

Not sure if you would like me to squash these down commits.

tsukasa-au · 2025-10-20T11:57:10Z

This change should be in a good state to review.

samhed · 2025-10-21T10:58:53Z

Works great! Tested on Android 15

I would suggest we put this option as ON by default.

CendioOssman · 2025-10-24T06:10:31Z

I would suggest we put this option as ON by default.

What's your thinking here? I'd consider it very misbehaved for any other application to not respect my screen timeout. Applications that are passively used are normally the exception, not the rule.

core/rfb.js

docs/EMBEDDING.md

samhed · 2025-11-05T20:48:28Z

I would suggest we put this option as ON by default.

What's your thinking here? I'd consider it very misbehaved for any other application to not respect my screen timeout. Applications that are passively used are normally the exception, not the rule.

I would personally expect a remote desktop client to keep my screen awake. But perhaps that isnt the case for everyone.

If we dont want to enable this by default, I would at least move it out of "advanced".

CendioOssman · 2025-11-06T14:34:28Z

In what way do you think using remote applications differs from using local ones? Perhaps there is some room for automation here.

samhed · 2025-11-14T12:20:40Z

In what way do you think using remote applications differs from using local ones? Perhaps there is some room for automation here.

I use desktop applications and mobile applications differently. In my mind the norm is to have a significantly longer screen timeout, if any, on desktop. While a short timeout is probably quite common on mobile.

When connecting to a remote desktop via noVNC I'd like things to act more like a desktop. I'd be very annoyed if my desktop screen automatically locked after 30 seconds of inactivity.

tsukasa-au · 2025-11-17T05:43:41Z

I would personally expect a remote desktop client to keep my screen awake. But perhaps that isnt the case for everyone.

If we dont want to enable this by default, I would at least move it out of "advanced".

For the moment, I will keep the default set to false as it is quite easy to override when deploying noVNC, and the setting is saves on the client.

As for moving it out of "advanced", I can if you want... I am just very hesitant to move it, given that most other settings are in "advanced" (like show_dot, or the path settings).

samhed · 2025-12-03T12:36:57Z

For the moment, I will keep the default set to false as it is quite easy to override when deploying noVNC, and the setting is saves on the client.

As for moving it out of "advanced", I can if you want... I am just very hesitant to move it, given that most other settings are in "advanced" (like show_dot, or the path settings).

I'm fine with that. I understand your reasoning for keeping it set to false by default. Having it under advanced or not isn't a big deal. Given that @CendioOssman is satisfied with the review comments, I think we are ready to merge!

CendioOssman

There are some minor details left. And the linter isn't happy.

app/wakelock.js

tests/test.wakelock.js

Add a new configuration option `keep_device_awake` to allow noVNC to stop the local display from going to sleep. This is especially useful with view-only sessions. This new option has been added to the configuration UI, making it easier for users to configure. When this option is changed at runtime, we will request/release the wake lock. We only hold the view lock while connected to a server. We will also attempt to reacquire the wakelock if we lost it due to a visibility change (the tab becoming inactive, or during the transition into/from fullscreen). All existing unittests have been run, and the change has been manually tested in Firefox 145. Additional tests will be added later.

Add an error state to the WakeLockManager state machine. This adds a transition that can be detected from tests (it otherwise serves no purpose, and the system immediatly transitions back into the released state).

Dispatch an event on each state transition inside the WakeLockManager. This gives the unit tests something to synchronise on, allowing us to write fast, flake-free tests.

Add tests to for both the `rfb` side (calling into the new wakelock code), and the new wakelock class (which tracks the desired state and how to get there).

tsukasa-au · 2025-12-06T08:11:13Z

There are some minor details left.

Done.

And the linter isn't happy.

I believe I have fixed these now.

CendioOssman

Looks good to me!

Thanks for your work!

tsukasa-au force-pushed the add-wakelock-support branch from 644c520 to 78695ba Compare September 12, 2025 00:35

tsukasa-au force-pushed the add-wakelock-support branch 5 times, most recently from 63a63d1 to 428b1f7 Compare September 12, 2025 07:50

tsukasa-au force-pushed the add-wakelock-support branch from 428b1f7 to a6f157d Compare September 26, 2025 06:02

samhed added feature ui/full labels Oct 21, 2025

CendioOssman requested changes Oct 24, 2025

View reviewed changes

core/rfb.js Outdated Show resolved Hide resolved

CendioOssman requested changes Oct 24, 2025

View reviewed changes

docs/EMBEDDING.md Outdated Show resolved Hide resolved

tsukasa-au force-pushed the add-wakelock-support branch 2 times, most recently from 7ece518 to 1719d4b Compare November 17, 2025 05:36

CendioOssman requested changes Dec 4, 2025

View reviewed changes

app/wakelock.js Show resolved Hide resolved

tests/test.wakelock.js Outdated Show resolved Hide resolved

tsukasa-au added 2 commits December 6, 2025 19:00

Add error state for wakelock testing.

077c54f

Add an error state to the WakeLockManager state machine. This adds a transition that can be detected from tests (it otherwise serves no purpose, and the system immediatly transitions back into the released state).

tsukasa-au added 2 commits December 6, 2025 19:00

Expose WakeLockManager state transitions for tests

f4f2f8d

Dispatch an event on each state transition inside the WakeLockManager. This gives the unit tests something to synchronise on, allowing us to write fast, flake-free tests.

Add tests for the wakelock feature.

988e9da

Add tests to for both the `rfb` side (calling into the new wakelock code), and the new wakelock class (which tracks the desired state and how to get there).

tsukasa-au force-pushed the add-wakelock-support branch from 1719d4b to 988e9da Compare December 6, 2025 08:07

CendioOssman approved these changes Dec 8, 2025

View reviewed changes

Add wakelock support #1984

Are you sure you want to change the base?

Add wakelock support #1984

Uh oh!

Conversation

tsukasa-au commented Aug 26, 2025

Uh oh!

CendioZeijlon commented Aug 28, 2025

Uh oh!

tsukasa-au commented Aug 29, 2025

Uh oh!

CendioZeijlon commented Aug 29, 2025

Uh oh!

CendioZeijlon commented Sep 10, 2025

Uh oh!

tsukasa-au commented Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tsukasa-au commented Sep 12, 2025

Uh oh!

tsukasa-au commented Oct 20, 2025

Uh oh!

samhed commented Oct 21, 2025

Uh oh!

CendioOssman commented Oct 24, 2025

Uh oh!

Uh oh!

Uh oh!

samhed commented Nov 5, 2025

Uh oh!

CendioOssman commented Nov 6, 2025

Uh oh!

samhed commented Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tsukasa-au commented Nov 17, 2025

Uh oh!

samhed commented Dec 3, 2025

Uh oh!

CendioOssman left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tsukasa-au commented Dec 6, 2025

Uh oh!

CendioOssman left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

tsukasa-au commented Sep 12, 2025 •

edited

Loading

samhed commented Nov 14, 2025 •

edited

Loading