Rounding is off-by-one #490
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?
Here is a layout:
The autogenerated file is as such:
As you can see, the last three elements all have a computed width equal to 12px. However, their parent node has a computed width equal to 11px!
Funnily, that's not the behaviour that I observe in my app (but it is still broken). Instead, the left panel computed width is 11px, the right panel computed width is 12px, and the children computed width is 11px wide (making them smaller than their parent, instead of bigger as in the aforementioned issue). You can witness this issue here (you can play with the container width to see that the other sizes aren't affected).
This is pretty easily solvable by using the absolute position instead of the local position here.
I had that at first, but the generated tests are failing against the result from chrome with this. Not sure how to combine this with an assertion on the chrome outputs. Use this just with an experimental?
Hm ... would that fix everything if the tests relying on Yoga-only features (such as rounding) were manually written?
Jep, those tests must be manually written. But also the percentage feature in some cases relies on the rounding things. One idea could be to introduce an experimental feature which rounds "correctly" which is enabled per default, and can be disabled for the tests, to still relie on chrome.
Hm I see. However, I'm not completely sure it's only because of the position: if I take an 13px element and split it in two equal parts (each ending up being 11.5px), then the rounding will adjust them to respectively 12px and 11px. The issue is when the second one has children, because in this case those children still think that they are 11.5px, and so the rounding put them at 12px (because they don't benefit from the fractial leftovers from their parents).
Maybe passing the leftovers from a node to its children would be enough to fix this...
You can see a better example here. The blue box is the parent, and its child (the yellow box) takes more space than it should.
I have made a tentative fix (
396050e1dd (diff-2886721427e8c2829a4b8cd59f1c62c9)
), I'll check later if it actually works in every case.The previous commit was faulty, but the following one works fine in all the cases I've stress-tested:
acfe842a21
A single test is failing (rounding_nested_3, I think), but I haven't discovered yet how experiment assertions such as those used for the rounding experiment are generated from the fixtures, so I haven't been able to fix it.
Would you like a PR with this commit?
@woehrl01 Would you accept a PR that would add support for
expect-*="<number>"
attributes, to override the values returned by Chrome? This way the tests could still be mostly autogenerated.sounds like a good idea, but the decision is up to @emilsjolander .
I fixed it in
aa5b296ac7
. 🎉(Sorry @arcanis, I had not seen your approach before I landed my solution today... 😳 )
Happy to see it fixed, whoever landed the final hit! 👍
I've checked my use case, and it seems to work fine now, good job :)