fix: don't report cancellation as a sync error; fix accent-text contrast and stark CTA fill - #65
Merged
Merged
Conversation
…ast and stark CTA fill Three unrelated fixes surfaced by this session's reader testing: - DebouncedSaver and PageProgressSaver both caught CancellationException (a subclass of Exception) and reported it through onError as if it were a real failure, so leaving the reader mid-save -- a completely normal part of navigating away -- showed a 'StandaloneCoroutine was cancelled' Snackbar. Both now rethrow cancellation instead. - EpubReaderScreen's chrome (last commit) was built from a from-scratch Material scheme instead of the app's own grimScheme(), losing its surfaceTint = Color.Transparent and looking translucent in dark reading themes. Now built with grimScheme() itself, using the app's actual accent/OLED-black preference (plumbed from Settings via the ViewModel), same as the rest of the app. - Theme.kt's onColorFor() picked white/near-black button text from a flat 0.4 luminance cutoff. Every one of the 6 accents falls under that cutoff and got white text, but for every single one, near-black text actually contrasts roughly twice as well (5.5-7.5:1 vs 2.5-3.4:1) -- a UI/UX audit prompted by 'the continue reading button ... comes as stark with white text on the black theme' traced the stark-text half of that complaint here. Replaced the cutoff with an actual WCAG contrast-ratio comparison, exported the function so SettingsScreen's accent-picker checkmark (which duplicated the same white-text logic inline) can share it instead of silently breaking on some future accent. - The other half of that complaint -- the button's large solid-fill block reading as too stark against a neutral/black page -- is a separate, Material3-idiomatic issue: BookDetailScreen's four Continue/Read/Listen/Open-with CTAs used raw primary/onPrimary (the full-saturation accent, meant for small high-emphasis elements) for a 52dp full-width block. Switched them to primaryContainer/ onPrimaryContainer, the softer accent-tinted fill grimScheme() already defines for exactly this kind of large prominent element. Button height (52dp) is an intentional, consistent convention shared with both Sign-in buttons on the login screen, so left unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M421Z8byhEsWKMq7eWWqDN
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
1 participant
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.
Three fixes from this session's on-device reader testing:
"StandaloneCoroutine was cancelled" Snackbar on leaving the reader
DebouncedSaverandPageProgressSaverboth caughtCancellationException(a subclass of
Exception) and reported it throughonErroras a realsync failure. Leaving the reader mid-save — a completely normal part of
navigating away — showed that error to the user. Both now rethrow
cancellation instead of reporting it.
Translucent reader controls in dark mode
A side effect of the previous PR: the EPUB reader's chrome was built from
a from-scratch Material scheme instead of the app's own
grimScheme(),losing
surfaceTint = Color.Transparentand looking washed-out/translucentin dark reading themes. Now built with
grimScheme()itself, using theapp's actual accent and OLED-black preference (plumbed from
Settingsviathe ViewModel) — the same colors the rest of the app uses.
"the continue reading button ... comes as stark with white text on the black theme"
Ran a UI/UX audit off this report. Two separate causes:
Theme.kt'sonColorFor()picked white/near-black button text from aflat 0.4 luminance cutoff. All 6 accents fall under that cutoff and get
white text, but for every single one, near-black text actually contrasts
roughly twice as well (5.5–7.5:1 vs 2.5–3.4:1). Replaced the cutoff with
an actual WCAG contrast-ratio comparison, and exported the function so
the Settings accent-picker's checkmark (which duplicated the same
white-text logic inline) shares it instead of silently breaking on some
future accent.
BookDetailScreen's four Continue/Read/Listen/Open-with CTAs used rawprimary/onPrimary(full-saturation accent, meant for smallhigh-emphasis elements) for a 52dp full-width block. Switched to
primaryContainer/onPrimaryContainer, the softer accent-tinted fillgrimScheme()already defines for large prominent elements. Buttonheight is an intentional, consistent convention shared with both
Sign-in buttons on the login screen, so left unchanged.
🤖 Generated with Claude Code