Sign up
View stargazersSign up

A dropped window that a snapping app tiled can come back narrower than its column#388

opened2d agobySSamanyu Das

Found while trying to reproduce a lost window for #314 on 8 November 2026. After a snapping app's quarter, a dropped T3 Code window can come back to its column 23 pt narrower than it was, because Miri takes the size the app shows while it is still applying Miri's resize as the app's own.

Steps to reproduce

  1. Run Miri Developer from main at 70dbc3b6 (engine 31be78d) with T3 Code (Nightly) tiled in a 1676 by 1394 column on the 27-inch display, and Magnet running.
  2. Drag T3 Code by its title bar below the 27-inch display's bottom edge and release.
  3. Within a moment, press Magnet's top-right quarter shortcut, Control-Option-I.
  4. Repeat. It happened in 1 of 6 drops.

A tool did the drags and pressed Magnet's shortcut 20 ms after release, and a recorder read window frames every 5 ms. The build had trace lines in the engine (verify-miri run 20261108-202747, drop 6).

Expected result

The window returns to its column's full frame, 1676 by 1394, with the width it had before the drop, as #314's second criterion asks.

Actual result

The window ended 1653 by 1394, 23 pt narrower, and Miri kept 1653 as the column's width. The engine's trace, with times from the release:

text
1+0.11 s Magnet's quarter (1280 by 705) starts a 1 s tile hold, and Miri writes the slot
2+1.31 s the hold ends with the window not yet at the slot's origin, so Miri writes the slot again and waits for the app
3+1.40 s the window reaches the slot's origin at 1661 by 1245 (engine coordinates) and holds still for 140 ms
4+1.54 s the wait ends: the origin is at the slot, so Miri records a refusal and adopts 1661 by 1245 (adopt_refused_frame)
5+1.56 s T3 Code goes on growing its height to the column's, but the adopted width stays

The wait (NativeResizeStart::catching_up in vendor/paneru/src/ecs/drag/tiling.rs) checks only whether the window reached the slot's origin, not its size. No window became unreachable or off-screen.

Acceptance criteria

  • An engine test with an app that reaches the slot's origin before it finishes applying the slot's size, and pauses under 200 ms, keeps the column's width after a snapping app's tile: it fails before the fix and passes after it (make engine-test).
  • Following the steps above, T3 Code returns to its column's full frame with its width in 20 of 20 quarter drops. Check with a 5 ms frame recording in a verify-miri run.

Miri version or commit

main at 70dbc3b6, engine 31be78d, with trace lines added for the run

macOS version and Mac model

macOS 27.0.1 (26A434), MacBook Air M3 (Mac15,12)

Displays and arrangement

27-inch external above the built-in display, separate Spaces on

Dependency and status (coordination, 10 Nov 2026)

  • Builds on another thing? Yes. Engine fix is paneru#147 (merged). Miri still needs an engine pin PR onto current main. The live 20/20 full-frame criterion stays blocked while drops end on the wrong display tracked by #390. Does not depend on #377, #350, #333, #376, or #386.
  • Evidence: paneru#147 at 9e594e5 has engine tests that fail before and pass after; historical live runs on that engine showed 0 narrower of 20 valid drops (other failures were wrong-display / unmanaged). No Miri pin on main yet.
  • Blocker: #390 wrong-display outcomes keep the 20/20 full-frame acceptance item unticked. Do not reinterpret that criterion.
  • Independent work now: pin 9e594e5 (or its merge commit) into Miri; re-run make engine-test / CI; live verify-miri quarter drops with 5 ms recording. Leave the 20/20 box unticked if any drop lands on the wrong display.
  • Next step: Miri engine-pin PR + verification under the live-test lock; serialize GUI lock and restore windows/displays.
  • Links: https://github.com/samanyudas/miri/issues/388 · https://github.com/samanyudas/paneru/pull/147 · https://github.com/samanyudas/miri/issues/390
SSamanyu Das20h ago

Status update (coordinator, 10 Nov 2026 4:20 AM Adelaide)

miri#406 pins vendor/paneru from 7be4df9 to 24fef41 (paneru#147's merge commit; fast-forward that also brings paneru#152 to #155, CI-only plus one Clippy fix). Head e3b61d5a: all required CI jobs green, make engine-test 1204/0, lint and build pass, lifecycle check holds, Sol (gpt-6.1-sol high) approved round 1 with no findings.

Live evidence (Magnet quarter shortcut 20 ms after release, 5 ms frame recording, live-test lock held, layout and widths restored after each run): runs 20261110-034914, -035139, -035535, -040113. 20 valid drops: 17 back at the full 1676×1394 column frame, 0 narrower, 3 on the wrong display (#390). 8 further drops excluded because the quarter never appeared. No lost windows. On main before the fix the narrow width appeared in 2 of 34 drops. A real hand drag was not tested.

Dependency: builds on merged paneru#147. The 20/20 full-frame criterion stays unticked because of #390 wrong-display drops; it can't pass until #390 is fixed.

Next step: merge decision on #406 is with Sam, since the issue's criterion isn't fully met.

SSamanyu Das8h ago

Note

🤖 Claude Opus 5.5 responding on behalf of samanyudas

The engine-test criterion holds on main, and the 20 of 20 drop criterion does not, because 3 of 20 valid drops ended on the wrong display (#390). No drop came back narrower. This issue stays open, with no criterion ticked.

Artifact: main at 9747ed26 (#406), which pins engine 24fef41, the merge of paneru#147. The live runs used a build of the PR branch with the same engine pin.

Criterion 1, engine test: met.

  • drag::part_c::an_app_that_reaches_the_slots_origin_mid_resize_keeps_its_column_width fails on engine c61a547 with the half-applied width, as paneru#147 shows, and passes on 24fef41.
  • make engine-test on the pin: 1204 passed, 0 failed. CI on #406 passed every job.

Criterion 2, 20 of 20 quarter drops: not met. The setup followed the steps above: a 1676 by 1394 column on the 27-inch display, Magnet's Control-Option-I 20 ms after release, a 5 ms frame recording, and the live-test lock held. A drop counts as valid only when the recording shows Magnet's 1280 by 705 quarter.

verify-miri runValid dropsBack at 1676 by 1394NarrowerOn the built-in display (#390)
20261110-0349145401
20261110-0351396501
20261110-0355354301
20261110-0401135500
Total201703

In 8 more drops, Magnet's quarter never showed, so they do not count. No window was lost. Run 20261110-035535 rose to load average 34 during its drops, because of other builds.

Judgment: on main before the fix, the narrower width showed in 2 of 34 valid drops, so 0 of 20 makes it less likely that the bug remains, but does not prove that it is gone. Not covered: a real hand drag.

Next: run the 20 drops again after #390 is fixed, and tick criterion 2 only at 20 of 20.