Add a today control and on-idle return to today to the calendar - #144
Merged
Conversation
A wall display left on last month looks current and is not. The period label doubles as a "today" button — tapping it returns to today, and it goes inert (reading "· Today") when already there. Desktop also gets a separate 📅 button; on a phone the header has no room for one, so the label carries it alone. It is a ButtonBase, so it is keyboard reachable. Auto-return brings the view back to today after a configurable idle period (default 20 minutes, 0 or empty disables), stored per device in calendarWidgetSettings.idleReturnMinutes. Any interaction restarts the countdown; the timer is cleared on unmount and does not run while the browser tab is hidden. Only the date is reset — a household that chose week view keeps it. Note the countdown restarts rather than resumes when a hidden browser tab becomes visible again. That is invisible on a kiosk but means auto-return rarely fires on a phone that backgrounds often; pausing instead would be a reasonable change if that matters. Pure helpers (duration parsing, same-day comparison) are in utils/calendarIdleReturn.js with tests.
mrramam
changed the title
mrramam
changed the title
The isViewingToday flag is derived from currentDate, which is set once at mount and never rolls over at midnight. After midnight, the header would claim a stale date is today, and the Today control would stay disabled exactly when the user most wants to tap it. Remove the '· Today' indicator appended to the period label, drop the disabled prop and its associated Tooltip suppression props and dead Mui-disabled styling from both the label ButtonBase and the desktop Today IconButton, and remove the Box wrapper that existed solely to give MUI's Tooltip a non-disabled child (moving the responsive display style directly onto the IconButton). Delete the widget.todayIndicator i18n key from en and es locales. goToToday's early-return guard and isViewingToday itself are preserved — the idle auto-return effect still uses the flag and staleness there is harmless.
The today control compared currentDate against a new Date() captured at render. A display with refresh disabled can cross midnight without re-rendering, leaving the comparison stale-true and the control inert at the moment it is actually needed. Evaluate now inside the handler, and mark activity on every tap since the user did interact.
jherforth
added a commit
that referenced
this pull request
Aug 31, 2026
…live (#144 follow-up) features.md said the period label goes "Inert when already there". It did in the first commit of #144, and the contributor removed it two commits later under the apt title "remove stale 'today' assertion from header" — the docs just did not follow. Removing it was right. Whether the view is on today is computed at render, so a display sitting on today across midnight would keep asserting "Today" while showing yesterday: precisely the stale-wall-display problem the PR set out to fix, reintroduced in the label. The control now evaluates the date at click time and stays live, which is worth writing down so nobody "fixes" it back. Docs only; no behaviour change.
Owner
|
Merged. The two follow-up commits are the best part of this — catching that a rendered "Today" assertion goes stale across midnight, on a feature whose whole point is that stale wall displays lie, is a nice bit of self-review. One tidy-up pushed in 4539c70: Two things I left alone, both deliberate on your part and I agree with them:
Verified merged with main rather than the branch alone: 130 client, 208 server, i18n 721/721, build clean, no conflicts. |
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
2 participants
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.
A wall display left on last month looks current and is not.
Today control — the period label is now a button; tapping it returns to today, and it goes inert (reading
· Today) when already there. Desktop keeps a separate 📅 button; on a phone the header has no room for one, so the label carries it alone. It's aButtonBase, so keyboard reachable.Idle auto-return — returns to today after a configurable idle period, default 20 minutes,
0or empty disables. Stored per device incalendarWidgetSettings.idleReturnMinutes. Any interaction restarts the countdown; the timer clears on unmount and doesn't run while the browser tab is hidden. Only the date resets — a household that chose week view keeps it.One behaviour worth flagging: the countdown restarts rather than resumes when a hidden browser tab becomes visible. Invisible on a kiosk, but it means auto-return rarely fires on a phone that backgrounds often. Happy to change it to pause if you'd prefer.
Pure helpers are in
utils/calendarIdleReturn.jswith tests.features.mdupdated.Tested on a real instance at desktop and phone widths, both themes. Node 20 (matching
ci-tests.yml): client 144, server 190,check:i18n715/715, build clean.