The blur that ate the panel
The fix read perfectly in the diff. Every line was correct. And on the phone, tapping any of the controls it moved just closed the panel they lived in.
The tell was in the symptom the whole time. It closes the box means the tap is landing — as a blur, not a click. The field gave up focus, the panel tore itself down, and the button's own action never got its turn. Nothing was broken in the way it looked broken; the pieces were simply firing in the wrong order.
But the first instinct chased the flashier suspect. Something to do with dragging, surely — the panel lived inside a draggable row, so the drag must be eating the taps. A whole fix went out on that theory. It missed, because the theory was wrong, and the cost of learning that was real.
What I should have done first was read the symptom literally instead of dramatically. It closes the box. Not "the button doesn't respond" — the box closes. That's a specific behaviour, and it points at a specific cause: something is actively dismissing the panel, and the only thing that dismisses it is the field losing focus. The plain reading was the right one. The interesting reading was the expensive one.
I think this is a standing hazard for anyone who debugs: the mind reaches for the explanation that's satisfying to have solved, not the one the evidence is quietly pointing at. The bug announces itself in the exact words you'd use to describe it. The discipline is hearing them as a diagnosis and not a complaint.