4.0 KiB
Fresh source review: mounted overlay lifecycle repair
Reviewed exact commit e44f07565cc7599d5c5a15a6b5599b4f5d105718, parent a357b22778e82e8dc75d853ecd70f04ed32a1ca7. The entire diff is 20 additions in two test functions; no production paint or event-handling changes. Read-only source/log review only: no compiler, tests, app input, Gitea, or root source edits by this reviewer.
No actionable defect found in the repair. The parent's explanation is a sufficient source-grounded cause of both initial target-coverage failures. The original tests I authored omitted an Iced lifecycle step; the source review did not catch that before the first actual run. Neither that omission nor this correction is evidence that production target painting is defective or accepted.
Primary evidence
Actual dependency: .local/toolchain/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/iced_runtime-0.14.0/src/user_interface.rs.
:93–117:UserInterface::buildreconciles widget state and lays out the base, but constructsoverlay: Noneeven when the supplied Cache has previous widget state.:195–294:updateobtains the actual root overlay, runsoverlay.layout, and assignsself.overlay = Some(...). Those operations are outside thefor event in eventsloop, so an empty event slice performs this necessary layout without synthesizing pointer/keyboard input.:490–535:drawresets the renderer, draws the base, then returns if the retained overlay is absent. Both fixtures use a blank Space base, so their initial frame contains no custom popup and cannot satisfy a target-row contrast requirement.:588–590:into_cacheretains widget state, not the overlay layout. The chooser's second controlled rebuild must therefore initialize the new UserInterface's overlay too.- Desktop
context_menu.rs:564–581andforms/reference_chooser/widget.rs:366–387actually supply the expected overlays when their menu/chooser is present. There is no missing production overlay condition requiring another correction.
At a357, the menu test's first loop has movement=None and draws immediately after build; its separately measured MenuOverlay is unrelated to UserInterface's retained overlay field. The chooser test also draws immediately after each build. The archived log tails in .local/allocation-union-20260912/context-menu-a357b22.log and chooser-a357b22.log report the new tests failing at their first positive cue assertion (11/12 and 13/14 respectively), consistent with this missing initialization. The logs alone do not prove pixel composition; the control flow above supplies the causal evidence.
Exact correction and limits
context_menu.rs:1218–1227 now performs ui.update(&[], ...) before drawing, including the initial frame; the second frame's extra empty update is harmless and preserves the keyboard-chosen focus. forms/reference_chooser/widget.rs:1120–1129 does the same after every build. Both assert no messages were emitted by layout. Neither inserts a synthetic focus/highlight, changes a threshold, chooses a replacement pixel region, skips a failing assertion, nor changes Enter identity/repetition checks. Real keyboard movement and the controlled chooser cache/rebuild remain in place.
The pixel thresholds, clipped row geometry, screenshot dimensions, and action/candidate assertions are unchanged. No competing source explanation is needed to account for the initial blank-overlay frames. Remaining WGPU rasterization/geometry/text proximity questions must still be resolved by the parent's rerun; this review does not predict or claim a pass. If a repaired run still fails, inspect that actual rendered frame before changing paint or weakening the evaluator. Retain the original failed receipts and unchanged-input evidence.
Reviewed repaired file SHA-256 values:
crates/oa-desktop/src/context_menu.rs:03990ad926c6221d091b07e496b0614f264c9785f1489896be16e3711570ca55.crates/oa-desktop/src/forms/reference_chooser/widget.rs:57f21b2e438e7fc89a0a33412f8e43d9b3f7e59042c48a025bbbebe3d59467c8.