The rich-text engine already fully supported RichStyle.Strikethrough
(HTML serialization, parsing, and rendering); only the toolbar control
was missing. Adds an "S" FormatButton next to Bold/Italic/Underline,
wired the same way (onToggleStyle + isStyled toggle state), plus the
format_strikethrough string resource for its onClickLabel.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds friction to the "Report a Problem" form: a required email field (basic
local-part@domain.tld validation), a required consent notice about being
contacted at that address, and a 200-character minimum on the comment field
with a live "x/200" counter that turns red (with the field outline) until the
threshold is met. Submit stays disabled until both the comment and email are
valid, mirroring and extending the existing SUBMITTING gate. The email rides
along on DebugReport (userEmail) so it round-trips through the storage JSON
and the exact payload that's previewed, copied, saved, and POSTed. The new
ViewModel-level guard on submit() also fully integrates with the #161
success-confirmation dialog: invalid attempts never reach SUBMITTING/SUCCEEDED,
so the dialog flow is unaffected.
Closes#159
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
MainActivity.onCreate only parsed the incoming intent (pendingCompose /
pendingOpenMessageId) when savedInstanceState == null, on the assumption
that a non-null value always means a config-change recreation (e.g.
rotation), where Android redelivers the same, already-handled intent and
re-parsing would just navigate to a duplicate destination.
But Android also passes a restored, non-null savedInstanceState when it
recreates the activity after the process was killed in the background and
is then relaunched by tapping a notification. There, intent is the new
tap, not a replay, but the guard swallowed it exactly like a rotation, so
pendingOpenMessageId was never set and the tap silently landed wherever
the restored back stack was (typically the mailbox) instead of the
message. That's the #157 regression from the original fix in a6ec00d
(#56). pendingCompose (mailto:/share intents) went through the identical
guard and had the same latent bug.
Replace the savedInstanceState check with IntentHandledMarker, which
marks the Intent instance itself once parsed. A config-change recreation
redelivers that same marked instance, so it's correctly skipped; a
genuinely new intent -- warm via onNewIntent or cold via onCreate after a
process-death relaunch -- is never marked yet, so it's always parsed.
This dedupes on the intent's own identity instead of an unreliable proxy
for it, so it can't confuse the two recreation paths.
Adds IntentHandledMarkerTest covering the marking contract: unhandled on
first look, recognized as handled on a redelivered instance, and still
unhandled on a freshly constructed (but content-equal) instance -- the
process-death case.
Closes#157
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace the small inline "Report sent. Thank you!" text with an AlertDialog
carrying the fuller thank-you/no-guarantee message, and gate the screen's
auto-navigate-on-delete LaunchedEffect so it no longer fires while a submit
is in flight or has just succeeded — the dialog's acknowledgement is what
calls onDone() for that path instead. This closes the race where
ReportUploadWorker deletes the report row (and thus flips state.exists to
false) moments after SubmitUiState.SUCCEEDED, which could previously
navigate the user away before the confirmation was ever visible. Discard
and the other non-success paths (FAILED/UNAVAILABLE) are unaffected and
still auto-navigate immediately.
Closes#161
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
iCloud's guided setup screen previously linked only a generic Apple ID
sign-in page and had no two-factor help link, unlike Gmail. Apple also
requires two-factor authentication before it will issue an
app-specific password, so:
- MailProvider.ICLOUD.appPasswordHelpUrl now points at Apple's actual
app-specific-password instructions (support.apple.com/en-us/102654)
instead of the generic appleid.apple.com landing page.
- MailProvider.ICLOUD.twoFactorHelpUrl now points at Apple's dedicated
two-factor-authentication article (support.apple.com/en-us/102660),
so the existing generic 2FA-help button in AppPasswordSetupScreen
picks it up automatically, positioned the same as Gmail's (#152).
- The 2FA button now reads "How to turn on Two-Factor Authentication"
for iCloud instead of Google's "2-Step Verification" wording, via a
new app_password_2fa_help_icloud string.
Closes#153
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 18:34:14 -05:00
Jason RossClaude Opus 4.8github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* fix(onboarding): request notification permission after welcome screen renders
The POST_NOTIFICATIONS request fired from a MainActivity-root
NotificationPermissionEffect whose LaunchedEffect(Unit) ran on the very
first composition, so the system dialog could pop the instant the icon
was tapped — overlapping cold start/splash before any onboarding context
was on screen.
Move the effect into OnboardingWelcomeScreen so it fires once that screen
(the onboarding start destination) is composed and visible, with the
welcome content behind the dialog. Already-onboarded users launch
straight into the mailbox and never compose the welcome screen, so they
are unaffected; the API 33+ gate and the already-granted no-op are
preserved unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* test(onboarding): grant POST_NOTIFICATIONS in onboarding E2E to fix API 33+ flow
Moving the notification-permission request into OnboardingWelcomeScreen
(#151) means the system POST_NOTIFICATIONS dialog now pops when that
screen composes. On API 33+ (where it became a runtime permission) the
dialog backgrounded the activity mid-flow, so OnboardingFlowTest failed
with "No compose hierarchies found" on API 33/34/35/36/37 while API
29–32 stayed green.
Pre-grant the permission via a GrantPermissionRule so the dialog never
appears during the flow, guarded for API 33+ (the permission does not
exist below TIRAMISU, so grant nothing there to avoid erroring on older
devices). Adds the androidx.test:rules dependency that provides the rule.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Closes the #36 test-coverage gap left after the rich-text editor shipped:
- RichTextEditorTest.kt (new JVM unit test, 20 cases): exercises the
Compose-editor glue in RichTextEditor.kt that had no direct coverage -
applyStyle/applyBlock/applyLink, the AnnotatedString.toRichContent() <->
RichTextContent.toAnnotatedString() round trip across every span/link/
alignment/image/baseStyle channel, and the isStyled/hasBlock predicate
FormattingToolbar uses to light up its buttons. All plain TextFieldValue/
AnnotatedString/Color types, so it runs on the JVM with no emulator.
applyBlock/applyLink go from private to internal so the test can reach
them directly, mirroring applyStyle's existing internal visibility.
- ComposeScreenTest.kt (androidTest, following this file's existing
createAndroidComposeRule + fake-repository harness): one case taps the
bullet-list toolbar button and asserts the sent message carries the
<ul><li> HTML (block markers apply to the caret's line, so no fragile
on-device range selection is needed); another asserts every toolbar
button's click-action label matches its string resource, verifying the
accessibility claim (the labels are onClickLabel, not contentDescription).
Headings remain deliberately out of scope per the ticket - no model/
toolbar changes here.
Closes#36
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Reorder the Advanced block's SwitchRows to Push Mail, Load Remote
Images, Encrypt Local Cache, Require Screen Lock, then Allow insecure
STARTTLS fallback (moved last). Relocate the Background battery usage
row out of Advanced entirely and into the main settings list, directly
above local retention ("Storage on this device"), since it's common
enough (OEM battery optimization delaying push mail) that it shouldn't
be hidden behind "Advanced". Pure composable placement — no string
changes, no behavior change to any toggle.
Closes#162
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 17:46:59 -05:00
Jason RossClaude Opus 4.8github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2-Step Verification is a prerequisite for Gmail's app-passwords page, so
render the twoFactorHelpUrl button first when present, then the
appPasswordHelpUrl button. Previously the prerequisite link rendered
second, so a user without 2FA enabled would hit a dead end on the first
button before noticing the second. No visible change for Yahoo/iCloud,
which have no twoFactorHelpUrl.
Closes#152
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Persist a defaultAccountId preference (SettingsRepository/AppSettings,
following the existing key/field/setter pattern), add a "Default account"
switch to AccountSettingsScreen, and prefer it in ComposeViewModel's
from-account fallback (fromAccountId -> valid default -> first account).
Deleting the default account clears the preference (SettingsRepository
.clearDefaultAccountId), and a stale/foreign id is validated against the
current account list before use so it can never crash or point at a
missing account.
Closes#163
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Jason Ross
JMR-devandClaude Opus 4.8