Rest timer ignores when computer is going to sleep

[SergiiGalai]

Describe the bug
When laptop is on battery I have a quite small time to sleep the laptop (5 minutes and is set by the organization so I cannot change it). And when rest window appears during the rest computer goes to sleep mode. When in some time which is bigger than computer is woken up rest window is not closed automatically. This is annoying to click each 50 minutes on the skip button even when I already rest.

To Reproduce
Steps to reproduce the behavior:

1. Wait until rest window appears on the screen
2. Press the sleep button on the computer
3. Wake up computer in some time (e.g. half an hour so rest time is over)
4. Rest window ignores that time has changed and requires to continue a rest. So you have to press Skip button to continue working

Expected behavior
When computer wakes up rest window should respect the current system time and close automatically if it detects that rest time is over

Windows (please complete the following information in case you encountered the bug on Windows):

• Windows Version: Windows 10
• Workrave Version 1.10.45

[Chealer]

I am also experiencing this on 1 of the 2 OSes on which I use Workrave. The other one rarely goes to sleep, so likely simply doesn't expose the bug.

The clearly affected PC runs Windows 10 20H2 and exposes the bug at least weekly, most likely multiple times. I put the PC to sleep approximately 4 times a week. I do not notice the issue that often, but it probably happens as much.

Step #1 is not needed to reproduce. I believe a simpler method to reproduce would be:

1. Use the OS for 40 minutes
2. Suspend the OS
3. Resume the OS

After that, inspecting Workrave statistics should already show that the rest break timer is above 40 minutes. This affects Workrave 1.10.47 and affected at least 1.10.44 too.

The effect here is not so much that the rest break window stays, but rather that Workrave asks for rest breaks too often. I believe a more accurate title for the issue would be "Ignores time during which OS is suspended".

I would be curious to see if this occurs on GNU/Linux.

[pagin85]

I'd add to that noting that also the daily limit seems not to be working with suspend. Sometimes I do not shutdown my work laptop in the evenings (I know I should) and I start the next day with a reminder that I reached my daily limit and should stop for the day. I'd be happy about that, my boss much less....

Workrave 1.10.1; windows 10 pro 21H1 build 19043.1266

[EagleCreekNL]

Hello,

I'd like to add my vote to this request. I use hibernate a lot (sometimes it's just much more convenient) but the next day Workrave keeps bugging me, which can't be the point of the tool. Either it should autoreset, or I should be able to reset the timers manually. I've looked in the registery but haven't found an easy way to do so and I'd much rather see such an option be part of the software.

[AlexMKX]

Hi, here my 5c:
When I closing laptop lid for an 1 hour, 5 mins before rest break, and opening it 1 hour later (nb: I've just had a 1 hour rest break), workrave don't understand it and bugging me with "man, you need a rest" 5 minutes after. This ruins all workflow, because skipping or postponing will mess the timers out, and it keep bugging me untill I obey and do a "online" rest break.

Detecting sleep state on Windows is quite tricky. However, I'd suggest checking this repo https://github.com/AlexMKX/LenovoSleepFix
I've done this excercise couple years ago.

[belg4mit]

I'll also note that the same issue occurs with hibernation. Put the machine to rest one day, with three minutes until the next break, and the rest break will fire shortly after powering up the next morning. While both micro-breaks and rest breaks fail to heed hibernation, it seems the daily limit does (usually at least) properly take into account the passage of time/new date.

[tksoh]

Same problem here on Windows 11 with version 1.10.50. This issue is affecting the 'greenness' of workrave, as we have to keep the PC running while we step away, just so it can keep track of the timers correctly.

Given how long this issue is still not closed, perhaps I should be looking for other alternative soon.