mirror of
https://github.com/storytold/gridcraft.git
synced 2026-10-25 03:06:53 -06:00
neilcawseandClaude Opus 5.5
fa1dcd73e2
In 0.5.0 a click anywhere on the Home ribbon's Paste button (label, icon or dropdown arrow) froze the app for good. home() called paste.secondary_clicked() inside ctx.data_mut(); after any click egui answers that with ctx.input(), which takes the context lock the closure already holds, so the UI thread waited on itself. Sampling the hung 0.5.0 process on macOS shows the main thread parked in RawRwLock::lock_exclusive_slow under Context::write <- data_mut <- ribbon::home. #272 moved the query out of the closure; it landed after the 0.5.0 release, which is the build both reporters used. No test ever clicked the Paste button itself, which is how this shipped. The new test clicks it, then opens its menu with a secondary click and picks Paste Values, on a worker thread with a timeout so a regression fails instead of hanging the run. With #272 reverted it fails (egui's debug lock check panics after 10 s); with it, it passes. The Paste button gets an accessible "Paste" name so the test (and screen readers) can find it, the same way Pictures and Border presets are named. With the freeze gone, the button still did not do what it says: it pasted GridCraft's own copy only (GridState::system_clipboard was never assigned), so text copied in another app gave "Nothing to paste." The ribbon button, its options menu's Paste, the cell and header context menus and the macOS Edit menu now read the system clipboard through a new paste_text host service and paste it like Cmd/Ctrl+V does, falling back to GridCraft's own copy when there is no text (or no service, as on the web). Asking egui for the clipboard instead (RequestPaste) was tried and stalled the macOS event loop until the next input event. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>