Task row timer clock drift (on hidden window / when the browser suspends animations?)

[nekohayo]

I run app.invoicing.co in GNOME Web / Epiphany 47.4, as a web app, on Fedora 41.

However, I noticed that when I am inside a task (i.e. https://app.invoicing.co/#/tasks/some_hash/edit) and have the timer running, the timecodes drift compared to the system clock, even without suspending/resuming the computer; simply by me switching to another workspace or minimizing the window, so it's not the same as my previously reported issue #1744.

Demonstration video where you can see that the InvoiceNinja timer drifts / lags compared to a normal stopwatch (gnome-clocks) that measures the system time:

2025-04-13.-.clock.drift.in.task.timer.with.Epiphany.window.suspended.-.drifting.timer.at.the.bottom.in.the.row.mp4

As you can see here, my task timer indicates 03:08:00 when I focus out to another workspace, and when I come back exactly 60 seconds later, it indicates 03:08:33 (approximatively), and when I refresh the page a few moments later, it jumps from 03:08:42 to 03:09:27...

This was observed mainly on the bottom row timer. The big timer at the top does not seem to be affected, somehow (but maybe I didn't look properly).

---

Note that recent versions of WebKitGTK stop the animation clock (to save power) when the window is not visible, so I don't know if that might be related. If so, maybe part of solving this durably would be handling the visibility change events as suggested in #1871 (comment) to actually stop doing any CPU wakeups as long as the window is not visible, and resynchronize everything once it becomes visible again :)

[turbo124]

@Civolilah can you please investigate, may need to refresh the timer when the window 'focus' event is hit so that the timer can update