You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Otherwise, subsequent calls to layoutThatFits: may return a stale (pre-transition) layout.
transitionLayout is effectively a setNeedsLayoutAnimated: so this makes conceptual sense. transitionLayoutWithAnimation: already calls setNeedsLayout, I believe to ensure it gets an appropriate constrained size from _constrainedSizeForLayoutPass. If I'm wrong about that, then we can simply move that line down into transitionLayoutWithSizeRange:. If I'm right about that, we can insert a [self invalidateCalculatedLayout] in transitionLayoutWithSizeRange:. That's two invalidations, but they're cheap and fast.
Unfortunately this isn't fixed completely by #464. We have a case with the following sequence of events for a node. Here's a trace where a navigation bar is trying to change from 128 height to 84 height:
The Node <PISearch… lines near the bottom are explicit calls to layoutThatFits: from client code. The client explicitly measures the node and sets its frame as part of viewWillLayoutSubviews. He passes an unconstrained size range and we return him the pending layout that was generated before the layout transition.
As you can see the height reverts to 128 because of the stale layout that we returned. The layout transition call did not invalidate the node's layout (bump the version) because the size range passed to transitionLayout was a fixed size range that did not match the constrainedSizeForCalculatedLayout present in the logic added in #464. I created the linked PR to unconditionally invalidate the nodes layout in transitionLayout, unless the transition is canceled.
Otherwise, subsequent calls to
layoutThatFits:
may return a stale (pre-transition) layout.transitionLayout
is effectively asetNeedsLayoutAnimated:
so this makes conceptual sense.transitionLayoutWithAnimation:
already callssetNeedsLayout
, I believe to ensure it gets an appropriate constrained size from_constrainedSizeForLayoutPass
. If I'm wrong about that, then we can simply move that line down intotransitionLayoutWithSizeRange:
. If I'm right about that, we can insert a[self invalidateCalculatedLayout]
intransitionLayoutWithSizeRange:
. That's two invalidations, but they're cheap and fast.@maicki @nguyenhuy (when you're back from vacation) @appleguy Does this make sense?
The text was updated successfully, but these errors were encountered: