#87 — Bug: Multi-line-Paste-Bestätigungsdialog erscheint nicht #87

New issue

Closed

opened 2026-08-18 13:13:47 +02:00 by lena · 0 comments

lena commented

2026-08-18 13:13:47 +02:00

(Migrated from git.butzei.de)

Bug: Multi-line-Paste-Bestätigungsdialog erscheint nicht

As a list member,
I want to beim Einfügen von mehrzeiligem Text in ein leeres Eingabefeld gefragt werden, ob daraus mehrere Todos
angelegt werden sollen,
so that ich nicht jede Zeile einzeln einfügen muss und keine Zeilenumbrüche unbeabsichtigt durch Leerzeichen
ersetzt werden.

Status: Dieses Verhalten wurde bereits als Story #52 "Multi-line paste → split confirmation" umgesetzt und
laut docs/roadmap.md am 2026-07-19 ausgeliefert (ReactUi/src/components/TodoInput.tsx:44-51,
MultilinePasteConfirmDialog.tsx). Der Nutzer bestätigt jedoch, dass der Dialog in der aktuell von ihm genutzten
Version nicht erscheint — mehrzeiliger Text wird stattdessen wie vor #52 als ein einzelnes Todo mit durch
Leerzeichen ersetzten Zeilenumbrüchen angelegt. Damit gilt dies als Bug, nicht als neue Feature-Anfrage.

Repro (vom Nutzer bestätigt):

Text mit mehreren Zeilen kopieren, z. B. "Eins\nZwei\nDrei".
In das (nach aktuellem Kenntnisstand leere) Eingabefeld einfügen.
Erwartet: Bestätigungsdialog "Möchtest du das als 3 Punkte einfügen?" erscheint.
Tatsächlich: Kein Dialog; ein einzelnes Todo mit durch Leerzeichen ersetzten Zeilenumbrüchen wird angelegt.

Acceptance criteria:

Ursache verifiziert — naheliegendste Hypothese zuerst geprüft: läuft der Nutzer auf einem
Deployment/Branch, der TodoInput.tsx's Paste-Abfang tatsächlich enthält?
Ursache gefunden (siehe Root Cause unten).
Nach dem Fix: Einfügen von ≥2 nicht-leeren Zeilen in ein leeres Eingabefeld zeigt zuverlässig den
Bestätigungsdialog, wie ursprünglich in #52 spezifiziert.
Bestehende Tests zu #52 (TodoInput.test.tsx) bleiben grün; Regressionstest für das genau hier gemeldete
Szenario ergänzt.

Root Cause (gefunden 2026-08-07): Es gab bereits einen früheren, außerhalb des normalen Story-Prozesses
gelandeten Fix-Versuch (Commit b31a5fb, 2026-07-25, "fix: use textarea for todo input so multi-line paste works
on mobile") — <input type="text"> wurde durch <textarea rows={1}> ersetzt, weil <input> Zeilenumbrüche
schon vor dem paste-Event entfernt. Dieser Fix war nötig, aber nicht ausreichend: Der komplette
Split-Mechanismus hing weiterhin ausschließlich am onPaste-Handler und dessen e.clipboardData.getData('text')
— auf manchen mobilen Browsern (Clipboard-Vorschlagsleiste über der Tastatur, bestimmte IME-/OS-Einfügewege)
landet eingefügter Text jedoch direkt im Feldwert, ohne dass überhaupt ein klassisches paste-DOM-Event mit
nutzbaren clipboardData ausgelöst wird. In diesem Fall lief handlePaste nie, der native Einfüge-Wert blieb im
Textfeld stehen, und beim Absenden normalisiert das Backend (TodoTitle-Value-Object) die Zeilenumbrüche im
Titel zu Leerzeichen — exakt das gemeldete Symptom.

Fix: Zusätzlicher onChange-Fallback in TodoInput.tsx: Springt der Feldwert von leer auf ≥2 nicht-leere
Zeilen in einem einzigen Change (nur durch eine Masseneinfügung möglich, nicht durch normales Tippen), wird
derselbe Bestätigungsdialog geöffnet wie beim direkt abgefangenen paste-Event — unabhängig davon, ob und wie
der Text ins Feld gelangt ist. Deckt sowohl "clipboardData leer/nicht verfügbar" als auch "gar kein paste-Event
gefeuert" gleichermaßen ab, ohne dass die genaue mobile Ursache auf dem konkreten Gerät reproduziert werden
musste.

Out of scope for this story:

Erweiterung des Split-Verhaltens auf nicht-leere Eingabefelder (bewusste Einschränkung aus #52 — falls das
gewünscht ist, ist das eine separate, neue Story, kein Bugfix).

Umgebung (bestätigt, 2026-08-07): Getestet auf der aktuellen Live-Version der App, auf dem Handy (nicht
lokal/Desktop). Das schränkt die Hypothesen ein: eine veraltete Deployment-Version scheidet als Ursache aus (es
ist die Live-Version); übrig bleiben vor allem der Mobile/Touch-Pfad von clipboardData bzw. eine Regression,
die speziell auf dem echten Mobilbrowser auftritt und in der Desktop-Emulation nicht sichtbar war — deckt sich
mit der in #52/#96 bereits mehrfach dokumentierten Lücke "auf echtem Mobilgerät nie verifiziert".

# Bug: Multi-line-Paste-Bestätigungsdialog erscheint nicht **As a** list member, **I want to** beim Einfügen von mehrzeiligem Text in ein leeres Eingabefeld gefragt werden, ob daraus mehrere Todos angelegt werden sollen, **so that** ich nicht jede Zeile einzeln einfügen muss und keine Zeilenumbrüche unbeabsichtigt durch Leerzeichen ersetzt werden. **Status:** Dieses Verhalten wurde bereits als Story **`#52` "Multi-line paste → split confirmation"** umgesetzt und laut `docs/roadmap.md` am 2026-07-19 ausgeliefert (`ReactUi/src/components/TodoInput.tsx:44-51`, `MultilinePasteConfirmDialog.tsx`). Der Nutzer bestätigt jedoch, dass der Dialog in der aktuell von ihm genutzten Version **nicht erscheint** — mehrzeiliger Text wird stattdessen wie vor `#52` als ein einzelnes Todo mit durch Leerzeichen ersetzten Zeilenumbrüchen angelegt. Damit gilt dies als **Bug**, nicht als neue Feature-Anfrage. **Repro (vom Nutzer bestätigt):** 1. Text mit mehreren Zeilen kopieren, z. B. "Eins\nZwei\nDrei". 2. In das (nach aktuellem Kenntnisstand leere) Eingabefeld einfügen. 3. Erwartet: Bestätigungsdialog "Möchtest du das als 3 Punkte einfügen?" erscheint. 4. Tatsächlich: Kein Dialog; ein einzelnes Todo mit durch Leerzeichen ersetzten Zeilenumbrüchen wird angelegt. **Acceptance criteria:** - [x] Ursache verifiziert — naheliegendste Hypothese zuerst geprüft: läuft der Nutzer auf einem Deployment/Branch, der `TodoInput.tsx`'s Paste-Abfang tatsächlich enthält? - [x] Ursache gefunden (siehe **Root Cause** unten). - [x] Nach dem Fix: Einfügen von ≥2 nicht-leeren Zeilen in ein leeres Eingabefeld zeigt zuverlässig den Bestätigungsdialog, wie ursprünglich in `#52` spezifiziert. - [x] Bestehende Tests zu `#52` (`TodoInput.test.tsx`) bleiben grün; Regressionstest für das genau hier gemeldete Szenario ergänzt. **Root Cause (gefunden 2026-08-07):** Es gab bereits einen früheren, außerhalb des normalen Story-Prozesses gelandeten Fix-Versuch (Commit `b31a5fb`, 2026-07-25, "fix: use textarea for todo input so multi-line paste works on mobile") — `<input type="text">` wurde durch `<textarea rows={1}>` ersetzt, weil `<input>` Zeilenumbrüche schon vor dem `paste`-Event entfernt. Dieser Fix war nötig, aber nicht ausreichend: Der komplette Split-Mechanismus hing weiterhin ausschließlich am `onPaste`-Handler und dessen `e.clipboardData.getData('text')` — auf manchen mobilen Browsern (Clipboard-Vorschlagsleiste über der Tastatur, bestimmte IME-/OS-Einfügewege) landet eingefügter Text jedoch direkt im Feldwert, ohne dass überhaupt ein klassisches `paste`-DOM-Event mit nutzbaren `clipboardData` ausgelöst wird. In diesem Fall lief `handlePaste` nie, der native Einfüge-Wert blieb im Textfeld stehen, und beim Absenden normalisiert das Backend (`TodoTitle`-Value-Object) die Zeilenumbrüche im Titel zu Leerzeichen — exakt das gemeldete Symptom. **Fix:** Zusätzlicher `onChange`-Fallback in `TodoInput.tsx`: Springt der Feldwert von leer auf ≥2 nicht-leere Zeilen in einem einzigen Change (nur durch eine Masseneinfügung möglich, nicht durch normales Tippen), wird derselbe Bestätigungsdialog geöffnet wie beim direkt abgefangenen `paste`-Event — unabhängig davon, ob und wie der Text ins Feld gelangt ist. Deckt sowohl "clipboardData leer/nicht verfügbar" als auch "gar kein paste-Event gefeuert" gleichermaßen ab, ohne dass die genaue mobile Ursache auf dem konkreten Gerät reproduziert werden musste. **Out of scope for this story:** - Erweiterung des Split-Verhaltens auf nicht-leere Eingabefelder (bewusste Einschränkung aus `#52` — falls das gewünscht ist, ist das eine separate, neue Story, kein Bugfix). **Umgebung (bestätigt, 2026-08-07):** Getestet auf der aktuellen Live-Version der App, auf dem Handy (nicht lokal/Desktop). Das schränkt die Hypothesen ein: eine veraltete Deployment-Version scheidet als Ursache aus (es ist die Live-Version); übrig bleiben vor allem der Mobile/Touch-Pfad von `clipboardData` bzw. eine Regression, die speziell auf dem echten Mobilbrowser auftritt und in der Desktop-Emulation nicht sichtbar war — deckt sich mit der in `#52`/`#96` bereits mehrfach dokumentierten Lücke "auf echtem Mobilgerät nie verifiziert".