When paddingStart is 0, it should override paddingHorizontal #816
Reference in New Issue
Block a user
No description provided.
Delete Branch "rigdern/padding-start"
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?
Fixes #815
Problem
Imagine a node with this style:
{ paddingHorizontal: 10, paddingStart: 0 }
.After running layout on this node, we expect its computed
paddingStart
to be0
. However, it is actually10
.Fix
Consider the expression
paddingEdgeStart.getValue() > 0.0f
ingetLeadingPadding
. Why is0
handled like a negative number rather than a positive number? I suspect this should be>=
so0
is handled like the positive numbers (this is howgetTrailingPadding
works).History
It looks like
3a82d2b1a8 (diff-07b4949bf42749fde386e769ff08a124)
changed the operator from>=
to>
ingetLeadingPadding
. I suspect it was a mistake.getTrailingPadding
still uses>=
.Testing
I manually verified this using the code in #815 and added some unit tests to catch this bug and other similar issues.
Adam Comella
Microsoft Corp.
Hi Adam, great finding! Not every test is generated from the web, I think
YGComputedPaddingTest.cpp
is a good fit for this case.@woehrl01 thanks for the suggestion. I added some unit tests to catch this bug and other similar issues.
shergin has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Pull request closed