Repository navigation
fix(clock): resync the date tick on every update - #1909
Merged
Merged
Conversation
The tick re-armed itself with a fixed 60000 ms delay, so the lateness of each timer accumulated and the clock drifted away from the minute boundary, never recovering. Each monitor has its own webview and drifts by a different amount, so the secondary toolbar could show the new minute several seconds after the primary one. Recompute the delay from the wall clock on every tick instead.
Contributor
 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
libs/ui/svelte/runes/date.svelte.tsaligns its first timer to the minute boundary, but then re-arms itself with a fixedsetTimeout(tick, 60000). Each timer fires a few ms late and the next one keeps that lateness, so the displayed minute slowly moves away from the real boundary and never recovers. Every monitor has its own webview, so each toolbar drifts by a different amount.Seen here (Seelen 2.8.8, two monitors,
seelen-uirunning for 4 days): sampling a screen capture of both clocks every ~60 ms across two minute changes, the minute changed at:07.3on the primary toolbar and at:34.5on the secondary one, with the same offsets in both minutes. So the secondary clock showed the new minute ~27 s after the primary one.Related to #94 (closed, but the last comments there say the clock is still behind).
Fix
Recompute the delay from the wall clock on every tick (the same expression the first tick already used), so the clock re-aligns to the boundary after every update instead of keeping the accumulated drift.
Verification
Dev build (
seelen-ui+npm run build:ui) on Windows 11 with two monitors. To make the drift visible in minutes, I temporarily patchedsetTimeoutin the webview so every timer fires 300 ms late (test-only patch, not part of this PR), and sampled both toolbar clocks every ~40 ms for 7 minutes::00.63,:00.95,:01.24,:01.57,:01.91,:02.17,:02.52(about +0.31 s per minute, same on both monitors):00.32to:00.38every minute (the injected 300 ms, no accumulation)Also:
deno fmt,deno lintandts-type-checkpass (pre-commit hook), and CI is green on my fork.Not tested: waiting for the natural drift to build up in a build with this change (the injected delay stands in for it), and I have not confirmed what exactly made each webview drift in my 4-day session; timer lateness is the explanation that fits the numbers.