Documenteditor: knippen en slim plakken moeten de bedoelde tekstpositie vasthouden #2466

New issue

Closed

opened 2026-10-19 10:06:29 +00:00 by brenno · 0 comments

brenno commented

2026-10-19 10:06:29 +00:00

Owner

Gebruikersprobleem

Knippen en plakken horen precies op de selectie/caret van het moment van de opdracht te werken. Tijdens een trage klembordactie kan de gebruiker verder typen of elders klikken; de huidige asynchrone routes kunnen dan een ander bereik wissen of op een andere plek invoegen. Dit is een onderbouwd race-risico, nog niet live gereproduceerd.

Oorzaak op origin/main (`334604137`)

WysiwygNotesField._copySelection legt de selectie vast, wacht op Clipboard.setData en wist daarna de oude offsets in de dan actuele Quill-inhoud (lib/widgets/markdown_editor/wysiwyg_notes_field.dart:305-333). _smartPaste legt alleen de visuele caret vóór zijn awaits vast; het bronpad en het tabel-/beeldblokpad gebruiken later de actuele selectie (lib/widgets/parts/document_editor_layouts.dart:79-145). Eerdere #1667/#2138 repareerden verkeerde visuele plakposities in normale omstandigheden, niet tussentijdse edits tijdens klembord-I/O.

Oplossing

Maak klembordmutaties een atomaire gebruikershandeling: leg documentidentiteit, revisie, stand en selectie vast vóór de eerste await. Knippen verwijdert exact de gekopieerde selectie als de revisie nog klopt; bij een tussentijdse wijziging geen stil wissen van een ander bereik. Plakken gebruikt de oorspronkelijke positie of meldt duidelijk dat de bestemming is veranderd, zonder te gokken. Eén begrijpelijke undo-stap per handeling.

Acceptatie

Tests met gecontroleerd vertraagde Clipboard.setData/getData en tussentijds typen, verplaatsen van caret, standwissel en sluiten van tab. Controleer bron en Visueel, gewone tekst, tabel en afbeelding: geen verkeerd gewiste/ingevoegde inhoud, geen crash, juiste undo/redo.

## Gebruikersprobleem Knippen en plakken horen precies op de selectie/caret van het moment van de opdracht te werken. Tijdens een trage klembordactie kan de gebruiker verder typen of elders klikken; de huidige asynchrone routes kunnen dan een ander bereik wissen of op een andere plek invoegen. Dit is een onderbouwd race-risico, nog niet live gereproduceerd. ## Oorzaak op origin/main (334604137) WysiwygNotesField._copySelection legt de selectie vast, wacht op Clipboard.setData en wist daarna de oude offsets in de dan actuele Quill-inhoud (lib/widgets/markdown_editor/wysiwyg_notes_field.dart:305-333). _smartPaste legt alleen de visuele caret vóór zijn awaits vast; het bronpad en het tabel-/beeldblokpad gebruiken later de actuele selectie (lib/widgets/parts/document_editor_layouts.dart:79-145). Eerdere #1667/#2138 repareerden verkeerde visuele plakposities in normale omstandigheden, niet tussentijdse edits tijdens klembord-I/O. ## Oplossing Maak klembordmutaties een atomaire gebruikershandeling: leg documentidentiteit, revisie, stand en selectie vast vóór de eerste await. Knippen verwijdert exact de gekopieerde selectie als de revisie nog klopt; bij een tussentijdse wijziging geen stil wissen van een ander bereik. Plakken gebruikt de oorspronkelijke positie of meldt duidelijk dat de bestemming is veranderd, zonder te gokken. Eén begrijpelijke undo-stap per handeling. ## Acceptatie Tests met gecontroleerd vertraagde Clipboard.setData/getData en tussentijds typen, verplaatsen van caret, standwissel en sluiten van tab. Controleer bron en Visueel, gewone tekst, tabel en afbeelding: geen verkeerd gewiste/ingevoegde inhoud, geen crash, juiste undo/redo.

brenno added the

bug

triage

labels

2026-10-19 10:06:29 +00:00

brenno added the

in-progress

label

2026-10-19 12:08:56 +00:00

brenno referenced this issue from a commit

2026-10-19 15:46:35 +00:00

fix(document): knip en plak op de vastgelegde positie, niet op gok (#2466)