[YogaKit] Removal of element messes up layout

[kovpas]

Report

• I have searched existing issues and this is not a duplicate

Issues and Steps to Reproduce

1. The initial state of the app:

• A red view with padding = 20
• A button that adds a label inside the red view

2. Once you press the button, a label (violet) is added inside the red view:

3. Once you press the button again, the label gets removed from the red view:

Expected Behavior

State 3 should look exactly like state 1

Actual Behavior

The layout of the state 3 gets messed up. Looks like yoga thinks that the label is still there, also padding gets added twice to the height of the red view.

Link to Code

Demo project is here

[artman]

Facing this issue, too.

[d16r]

@emilsjolander I'm kinda stumped about this one...
This is the correct layout when the Violet button is inserted.

1.{*wm: LAY_EXACTLY, hm: LAY_EXACTLY, aw: 414.000000 ah: 736.000000 initial
2.{*wm: EXACTLY, hm: AT_MOST, aw: 414.000000 ah: 736.000000 measure
2.}*wm: EXACTLY, hm: AT_MOST, d: (414.000000, 90.000000) measure
2.{wm: EXACTLY, hm: EXACTLY, aw: 414.000000 ah: 90.000000 flex
2.}wm: EXACTLY, hm: EXACTLY, d: (414.000000, 90.000000) flex
2.{[skipped] wm: EXACTLY, hm: EXACTLY, aw: 414.000000 ah: 50.000000 => d: (414.000000, 50.000000) flex
2.{wm: LAY_EXACTLY, hm: LAY_EXACTLY, aw: 414.000000 ah: 90.000000 stretch
3.{*wm: EXACTLY, hm: EXACTLY, aw: 374.000000 ah: 50.000000 flex
3.}*wm: EXACTLY, hm: EXACTLY, d: (374.000000, 50.000000) flex
3.{[skipped] wm: LAY_EXACTLY, hm: LAY_EXACTLY, aw: 374.000000 ah: 50.000000 => d: (374.000000, 50.000000) stretch
2.}wm: LAY_EXACTLY, hm: LAY_EXACTLY, d: (414.000000, 90.000000) stretch
2.{[skipped] wm: LAY_EXACTLY, hm: LAY_EXACTLY, aw: 414.000000 ah: 50.000000 => d: (414.000000, 50.000000) stretch

This is the changes when you remove the violet button. Looks like the container isn't being remeasured.

1.}*wm: LAY_EXACTLY, hm: LAY_EXACTLY, d: (414.000000, 736.000000) initial

1.{*wm: LAY_EXACTLY, hm: LAY_EXACTLY, aw: 414.000000 ah: 736.000000 initial 2.{*wm: EXACTLY, hm: AT_MOST, aw: 414.000000 ah: 736.000000 measure 2.}*wm: EXACTLY, hm: AT_MOST, d: (414.000000, 130.000000) measure 2.{[skipped] wm: EXACTLY, hm: EXACTLY, aw: 414.000000 ah: 130.000000 => d: (414.000000, 130.000000) flex 2.{[skipped] wm: EXACTLY, hm: EXACTLY, aw: 414.000000 ah: 50.000000 => d: (414.000000, 50.000000) flex 2.{[skipped] wm: LAY_EXACTLY, hm: LAY_EXACTLY, aw: 414.000000 ah: 130.000000 => d: (414.000000, 130.000000) stretch 2.{[skipped] wm: LAY_EXACTLY, hm: LAY_EXACTLY, aw: 414.000000 ah: 50.000000 => d: (414.000000, 50.000000) stretch 1.}*wm: LAY_EXACTLY, hm: LAY_EXACTLY, d: (414.000000, 736.000000) initial

[emilsjolander]

Perhaps some dirty flag isn't being set correctly? However I would be very surprised if this is a bug in the C code and not the objc bindings as we aren't facing any similar issues on other platforms.

[woehrl01]

@kovpas Does the behaviour change if you both call applyLayout(preservingOrigin: false) (see the false)

[tadeuzagallo]

@woehrl01 Changing preserveOrigin: false doesn't modify the behaviour.

@emilsjolander even if I manually mark all the views as dirty it still doesn't change the layout. The curious bit is that this doesn't happen with React Native, which is using the same bindings, right?

[lucdion]

This is maybe also related to this issue #603, which is the reversed problem. Adding an element don't relayout its siblings.

[kovpas]

@woehrl01 no, as @tadeuzagallo said, nothing changes if I do preserveOrigin: false

@lucdion I saw #603... The reason I decided to fill a separate issue is that I don't really think it's related: In the case of #603, the view hierarchy remains the same, only yoga layout hierarchy is changed (by setting isIncludedInLayout to false).

In my case, view hierarchy changes which leads to the messed up layout.

[d16r]

So, this seems like a UIKit issue. If you set a breakpoint in YGLayout's YGMeasureView function you can see that when we call sizeThatFits: on a plain UIView with no subviews, it is returning a height of 90.

That height of 90 + 40 padding (top and bottom, 20) explains the height of 130. It's unclear why UIView is returning 90 as a height. But it makes it clear that it isn't a yoga problem.

[kovpas]

@dshahidehpour according to the documentation, this is intended behavior:

The default implementation of this method returns the existing size of the view.

I think what happens is that when there's the violet label inside the red view, sizeThatFits: gets invoked for this label, and red view's size becomes equal to the label's size. If there are no subviews, UIView's implementation of sizeThatFits: just returns bounds.size.

[artman]

Any progress on getting this merged in?