84f978f16d70f9660cb390a4d0ec675b5d48fa65
A closed call inside a group opened downward wherever it was pressed: the anchor asked for the group's top in every case, which is right for a tap on the call's heading and wrong for one at its foot, where what the reader wants held is the edge under their finger. It is the rule every other row has had since the anchoring went in, applied one level down. An open in the call's lower half now asks for no scroll at all, which is the same answer a row gets and for the same reason: the list holds the group's bottom edge, a Column keeps the calls below the one growing at their distance from it, so the growth comes off the call's top. The closing behaviour is untouched -- the arithmetic is the same shift, written as the one term it cancels down to, since where the call sits in the group and where the group sits in the viewport drop out of it. Checked with ktfmtFormat, compileDebugKotlin, lintDebug and testDebugUnitTest, and on the emulator against a sandbox group of six calls, with enough conversation behind it for the list to actually scroll -- a transcript shorter than the viewport pins to the bottom and gives every anchor the same answer, which is how this was missed. A call closed at 1321..1447: opened from 1430 it leaves the call below it at 1485 to the pixel and takes the growth off its top; opened from 1360 it leaves the calls above it where they are and moves the one below down by the full 327; closed again from 1400 it lands at 1338..1464, centred on the tap within a pixel.
Languages
Rust
53%
Kotlin
44.4%
Shell
2.6%