-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Yoga 3] Potential RTL paddingStart/paddingEnd bug #1657
Comments
FYI @joevilches for when you’re back from PTO |
@Omxjep3434 thanks for the report! I was able to repro and am able to see all the things you described in the report. It looks like the padding is properly applied but the width is the part that is incorrect and is taking both paddings into account, likely like you said in your guess where we interpret the end as the right side for that part. I will take a look and see if I can fix it |
…ng defined on parent Summary: This should fix facebook#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
…ng defined on parent Summary: This should fix facebook/yoga#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
…ng defined on parent Summary: X-link: facebook/yoga#1662 This should fix facebook/yoga#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
…ng defined on parent (facebook#1662) Summary: This should fix facebook#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
Ok that attached commit should fix the problem! We may wanna surround in errata, but this seems to be a super specific case where we need RTL, % child, and physical + relative edge defined for this to show up, so could go without it. We will see in code review. |
…ng defined on parent (facebook#44791) Summary: X-link: facebook/yoga#1662 This should fix facebook/yoga#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
…ng defined on parent (facebook#1662) Summary: X-link: facebook/react-native#44791 This should fix facebook#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
…tive padding defined on parent (facebook#44791) Summary: X-link: facebook/yoga#1662 This should fix facebook/yoga#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
…ng defined on parent (facebook#1662) Summary: X-link: facebook/react-native#44791 This should fix facebook#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
Awesome, glad to help! |
…ng defined on parent (facebook#44791) Summary: Pull Request resolved: facebook#44791 X-link: facebook/yoga#1662 This should fix facebook/yoga#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
…ng defined on parent (facebook#1662) Summary: X-link: facebook/react-native#44791 Pull Request resolved: facebook#1662 This should fix facebook#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Differential Revision: D58169843
…ng defined on parent (#1662) Summary: X-link: facebook/react-native#44791 Pull Request resolved: #1662 This should fix #1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D58169843 fbshipit-source-id: 5b4854dddc019285076bd06955557edf73ef7ec5
…ng defined on parent (#44791) Summary: Pull Request resolved: #44791 X-link: facebook/yoga#1662 This should fix facebook/yoga#1657. Rather insidious bug but we had code like ``` // The total padding/border for a given axis does not depend on the direction // so hardcoding LTR here to avoid piping direction to this function return node->style().computeInlineStartPaddingAndBorder( axis, Direction::LTR, widthSize) + node->style().computeInlineEndPaddingAndBorder( axis, Direction::LTR, widthSize); ``` That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D58169843 fbshipit-source-id: 5b4854dddc019285076bd06955557edf73ef7ec5
Report
I see a potential bug related to the RTL layout direction, and paddingStart / paddingEnd values when computing the % width of child nodes. Please see the code snippet below.
I am testing with the Javascript npm package version 3.0.4, but I think this bug may have been introduced in Yoga 3.0.2.
Also, while my code snippet demonstrates an issue with padding values, I found that the same issue exists for border width values.
Issues and Steps to Reproduce
Expected Behavior
The child width should be '5' in both the LTR and RTL scenarios. See comments in the code snippet above. I have commented the console output and put a description of the problem.
My guess at the issue
It seems there is a bug when computing the width of a child in regard to the parent's paddingStart/paddingEnd values, in combination with the RTL layout direction. In reference to my code snippet, it seems the layout engine is treating paddingEnd as paddingRight when RTL (which is incorrect) when computing the % width of a child node. However, this bug doesn't appear in the actual computed padding values, which are correct.
The text was updated successfully, but these errors were encountered: