[wmcparla]

Summary

#125: tapping a day in the month grid opened the day view with no way back to the month other than the drawer's view list, and Android's back left the Calendar tab altogether. The webmail on a phone (what the reporter saw in the iOS PWA) remembers that the day came from Month and puts a "back to month" arrow in the menu button's place (mobileReturnToMonth in calendar-app.tsx). This does the same in the app.

Changes

• CalendarScreen.tsx: openDay notes whether it was called from the month view (returnToMonth). While that is set and the day view is shown, the header shows an arrow labelled "Back to month" (the existing calendar.back_to_month string, already in every locale) instead of the menu button, and Android's back does the same through useBackWhileFocused. Changing view any other way (the drawer, a calendar link) clears it, so a day opened from the drawer or from a week day header keeps the menu as before.
• calendar-back-to-month-wiring.test.ts: checks that wiring.

Related issues

Closes #125

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactor / code quality improvement
• Chore / dependency update / CI change

Checklist

• I have read the Contributing Guide
• My code follows the project's code style and conventions
• I have run npm run typecheck and there are no errors (native has no lint script)
• The build passes (no npm run build in native; an x86_64 release APK, assembleGithubRelease -PallowDebugSignedRelease=true, builds and runs)
• I have tested my changes locally
• I have added or updated documentation if needed (none needed)
• I have updated translations (locales/) if my changes affect user-facing text (no new text: calendar.back_to_month exists in every locale; npm run i18n:check passes)
• I have included screenshots or a screen recording for UI changes

Tests: npx vitest run: 7106 passed, 163 skipped (the live Stalwart suites), 0 failed.

Tested by hand on the Android 16 emulator (1080x2424, 420 dpi), upstream b3b4230 against this branch, reading the screen's view hierarchy after each step:

Step	Before	After
Month, tap a day	day view, menu button	day view, "Back to month" arrow in its place
Tap the arrow		month view, menu button back
Month, tap a day, Android back	leaves the Calendar tab (to Mail)	month view
Month, tap a day, then "Go to today"		arrow stays; it returns to the month of today
Drawer > Day, then Android back	menu button; back leaves the tab	the same
Week, tap a day header	day view, menu button	the same

Not tested: iOS (the change is in the shared screen; the only platform-specific part is Android's back), a tablet.

Screenshots / demo

Day opened from the month, before	after

Notes for reviewers

• The drawer is out of reach while the arrow shows, as on the webmail's phone layout, where the arrow also takes the menu's place. Going back to the month brings the menu back.
• The arrow returns to the month of the day on screen, so after swiping a few days on, the month shown is the one those days are in. The webmail does the same.

🤖 Generated with Claude Code

[bulwark-warden]

I didn't find any problems. The test check passed on this commit (run).

I looked at every place on main that changes the view: changeViewMode, the date-link branch of applyDateLink, and openDay are the only callers of setViewMode (L521-L562, L620-L626). This PR sets or clears returnToMonth in each of them, and showBackToMonth also requires viewMode === 'day'.

Your manual test table doesn't say whether the free-scroll month was covered. That view (MonthScrollView) and the paged MonthView both call openDay (L1134-L1170), which sets returnToMonth whenever the view is month, so both paths go through the same code.

_{Bulwark Warden is an AI assistant and can be wrong. It answers from the docs, the code and earlier issues, and links its sources.}

[rathlinus]

Thanks, merged.