Problem
Capturing content via the Android share sheet (CaptureActivity) sometimes lands in the journal block with extra spaces the user didn't intend.
Root cause hypothesis
CaptureActivity.buildShareText() (androidApp/src/main/kotlin/dev/stapler/stelekit/CaptureActivity.kt:186-201) only handles which source (clipData vs EXTRA_TEXT vs EXTRA_SUBJECT) wins and blank-source fallback — it does no whitespace normalization on the winning string itself. CaptureViewModel.save() only calls .trim() on the whole string (outer whitespace only; CaptureViewModel.kt:54).
Many share sources (browsers sharing a text selection, apps that share HTML-derived text via EXTRA_TEXT) commonly include runs of internal whitespace, non-breaking spaces ( ), or repeated blank lines carried over from the source DOM/layout — none of which get collapsed before the block is saved.
androidApp/src/test/kotlin/dev/stapler/stelekit/CaptureShareTextTest.kt covers source-priority and blank-fallback behavior but has no test case for a string containing internal whitespace runs, confirming this path is untested/unhandled today.
Why this matters
- Silent formatting corruption on every capture from apps whose share payload isn't already clean plain text — the exact failure mode of the highest-frequency, lowest-friction entry point (see companion issue: auto-link + tag-suggest on capture).
Suggested scope
- Normalize whitespace in
buildShareText() (or a follow-up step in CaptureViewModel) before it reaches the block: collapse runs of spaces/tabs, normalize non-breaking spaces to regular spaces, collapse 3+ consecutive newlines to at most 2 — while preserving intentional single line breaks.
- Add test cases to
CaptureShareTextTest covering non-breaking spaces, repeated internal spaces, and excessive blank lines, mirroring a real Chrome/browser share payload.
References
androidApp/src/main/kotlin/dev/stapler/stelekit/CaptureActivity.kt
androidApp/src/test/kotlin/dev/stapler/stelekit/CaptureShareTextTest.kt
Problem
Capturing content via the Android share sheet (
CaptureActivity) sometimes lands in the journal block with extra spaces the user didn't intend.Root cause hypothesis
CaptureActivity.buildShareText()(androidApp/src/main/kotlin/dev/stapler/stelekit/CaptureActivity.kt:186-201) only handles which source (clipData vsEXTRA_TEXTvsEXTRA_SUBJECT) wins and blank-source fallback — it does no whitespace normalization on the winning string itself.CaptureViewModel.save()only calls.trim()on the whole string (outer whitespace only;CaptureViewModel.kt:54).Many share sources (browsers sharing a text selection, apps that share HTML-derived text via
EXTRA_TEXT) commonly include runs of internal whitespace, non-breaking spaces (), or repeated blank lines carried over from the source DOM/layout — none of which get collapsed before the block is saved.androidApp/src/test/kotlin/dev/stapler/stelekit/CaptureShareTextTest.ktcovers source-priority and blank-fallback behavior but has no test case for a string containing internal whitespace runs, confirming this path is untested/unhandled today.Why this matters
Suggested scope
buildShareText()(or a follow-up step inCaptureViewModel) before it reaches the block: collapse runs of spaces/tabs, normalize non-breaking spaces to regular spaces, collapse 3+ consecutive newlines to at most 2 — while preserving intentional single line breaks.CaptureShareTextTestcovering non-breaking spaces, repeated internal spaces, and excessive blank lines, mirroring a real Chrome/browser share payload.References
androidApp/src/main/kotlin/dev/stapler/stelekit/CaptureActivity.ktandroidApp/src/test/kotlin/dev/stapler/stelekit/CaptureShareTextTest.kt