Conversation
…t offset being changed erroneously
| /// An array of update closures that are applied **after** the `LayoutAttributes` is applied to the view. | ||
| public var updates: [Update] | ||
|
|
||
| /// An array of update closures that are applied **before** the `LayoutAttributes` is applied to the view after |
There was a problem hiding this comment.
Grammar is weird here
|
POS integration passed, surprisingly! https://github.com/squareup/ios-register/pull/127207 |
| controller = NativeViewController(node: child) | ||
| child.layoutAttributes.apply(to: controller.view) | ||
| // So the view has a reasonable size during creation/allocation, do this afterwards. | ||
| child.viewDescription.applyBeforeLayout(to: controller.view) |
There was a problem hiding this comment.
@watt Thoughts on this? This feels a bit better – init is all in a performWithoutAnimation, and I'd rather the view have at least a sane frame/bounds before we call the apply method here since some views don't generally work well if their frame/bounds has zero size.
There was a problem hiding this comment.
well, it's totally possible to have a view end up with a zero frame, and that's normal enough I'd still call that "sane", so I would probably do applyBeforeLayout first just for consistency. but in practice I don't think it will matter much either way.
kyleve
changed the title
|
You'll probably need to update against main and remove the legacy layout enum usage in the tests FYI. |
| controller = NativeViewController(node: child) | ||
| child.layoutAttributes.apply(to: controller.view) | ||
| // So the view has a reasonable size during creation/allocation, do this afterwards. | ||
| child.viewDescription.applyBeforeLayout(to: controller.view) |
There was a problem hiding this comment.
well, it's totally possible to have a view end up with a zero frame, and that's normal enough I'd still call that "sane", so I would probably do applyBeforeLayout first just for consistency. but in practice I don't think it will matter much either way.
3 participants
Bug
Simulator.Screen.Recording.-.iPad.10th.generation.-.2025-05-20.at.15.02.56.mp4
Notes
🐛 If you have a partial modal (or any other modal that resizes), and you resize the modal while the keyboard is focused and scrolled away from the top, to be taller (eg by adding content), the scroll view within would jump up towards the top.
Westin and I had dug in a while ago and thought it was just a UIKit bug, but it turns out it's an order of operations thing: You need to apply the new
contentSizeto the scroll view before you make its frame taller, otherwise UIKit's automaticcontentOffsetadjustment kicks you back towards the top.To fix this, I've added a
applyBeforeLayoutaddition toViewDescription.Config, which will be applied before theLayoutAttributes(except on initial view allocation – we still apply the attributes first so the view's properties are sensical).