irisandClaude Opus 5
cab21442d6
Reinstates the reverted downward-opening rows with the two defects that made the first attempt worse than what it replaced. The correction waited on the row's top edge and could wait up to half a second for it to move. A top edge also moves when the reader scrolls, so a correction still pending would wake on their drag, read the scroll distance as the row's growth, and undo it -- the transcript jumping on every expand and refusing to scroll back at all. It now waits on the row's *size*, which nothing but a resize changes. The second is why collapsing a group taller than the screen did nothing at all. Such a group is the list's own anchor item, so as it shrinks it slides down behind its anchored bottom edge and out of the viewport, and its size reads as null -- which `withTimeoutOrNull` cannot tell from the null that means the wait expired. The case most needing the correction was the one silently skipped. The wait now answers a value that a timeout cannot, and the distance is read off any row from the pressed one upwards, all of which move by exactly the row's growth. Verified on the emulator with ui-trace (~/.local/bin), which samples the accessibility tree at 60Hz and reports node bounds in device pixels: expanding and collapsing from a heading hold it to the pixel, collapsing from the foot bar holds all four rows below it, a drag 120ms after a tap is left alone, and scrolling back stays put for six seconds. ktfmt, lint and 85 tests clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>