ZacharyZhang-NYandClaude Opus 5.5
e6e5aea7a1
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
6 lines
1.7 KiB
Markdown
6 lines
1.7 KiB
Markdown
FAIL
|
|
|
|
- [P1] `crates/ely-lok/src/view/borders.rs:115` — The table snapshot still receives the latest view revision rather than its supplying batch's revision. `apply_batch` first calls `seen_revision`, which keeps the maximum because input completions and event batches can arrive out of order. Reproduce: receive a two-column table at revision 1, insert a column and process its revision-2 input completion, then apply the delayed revision-1 batch and drag its inner border. The kernel probe moved the new table's border from 3324 to 3624 twips without a stale error. Holding geometry through subsequent updates fixes round one's active-drag case, but this ordering still violates R5.3's read-revision requirement. Store the exact supplying `batch.revision` with the geometry, independently of the latest view revision, and add an out-of-order batch/completion regression. Evidence: `.work/R5.3-r2/probes.log`.
|
|
|
|
- [P2] `crates/ely-lok/src/view/input.rs:337` — Releasing a border ignores `event.position` and commits the last position received by `on_mouse_move`. GPUI only dispatches that move handler while the pointer is over the canvas, so dragging outside freezes the guide and commits the wrong width. Reproduce with a 450-pixel canvas: hold the inner column border at x=426.87, move to x=440, continue outside to x=480, then release. Dispatching through the same GPUI registrations and actual LokView handlers leaves the guide at x=440 and commits 5182 twips instead of the release position's 5782. Track pointer movement throughout the held drag and apply the release coordinates before issuing the single border command; cover release outside the canvas with an event-dispatch regression. Evidence: `.work/R5.3-r2/probes.log`.
|