Positioning issues for centered items when nested under stretched items #175
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Seeing this issues after pulling in https://github.com/facebook/css-layout/pull/171 in RN on iOS.
When there's a container view with unspecified cross-axis dimension, even though its calculated dimensions are known, it will perform a second recursive call. This second recursive call doesn't reset the position of recursively laid out children, and the offset to align any centered children will be applied twice.
Changing
isStyleDimDefined
on https://github.com/facebook/css-layout/blob/master/src/Layout.c#L1039 toisLayoutDimDefined
mitigates the issue for us, but I'm not sure if the underlying issue of offsets being applied twice is just hidden by this.cc @lucasr @jsendros
@javache could you provide a specific layout, please? #127 involves a centered item inside a stretched one and this example works fine in the latest version.
The critical difference might be that in Layout.js we reset all child layouts here: https://github.com/facebook/css-layout/blame/master/src/Layout.js#L1217-L1223
but in the native versions (.c/.java) we do not do this.
@javache: we do reset it but at a different place. Not on a computer right now but it's somewhere in the glue code that we have that's react native specific
Here's a test that shows this issue: https://gist.github.com/javache/f38f48b85d497da832ec
It works perfectly in JS (running
grunt test-javascript
) but fails when ran in C (usinggrunt transpile
).@vjeux we're probably missing that reset then somewhere now the layout is re-entrant for stretch.
We reset it here, which is after the entire pass happened: https://github.com/facebook/react-native/blob/master/React/Views/RCTShadowView.m#L160-L170
Hmm, the Java version of this test does pass, but I don't see any reset of properties happening there either. Any idea why it would be different @vjeux?
edit: Ah, we actually do at the start of layoutNodeImpl.