Direct children of a <vbox dir="reverse"> will display in the wrong position if they contain wrapped text either automatically or manually via e.g. <label style="white-space: -moz-pre-wrap;">wrapped text goes here</label> The position is offset exactly by the amount of extra height required for the wrapping. The computed height is correct, and adjacent elements will compute their position correctly if they do not contain wrapped text.
Created attachment 70494 [details] Test Case To see the effect, click on the vbox, the handler reverses the direction.
*** Bug 235898 has been marked as a duplicate of this bug. ***
Created attachment 170892 [details] [diff] [review] Proposed patch The basic problem is that the wrapping changes the size of the box in the layout loop. So we go through the "if the child was a block or inline (e.g., HTML) it may have changed its rect *during* layout" branch of Layout(). In this branch, the child's new rect is simply passed to SetBounds() when all is said and done. For normal-direction layout this is fine, since the child's rect will have changed size but not changed position. But for reverse layout, we need to keep the rect at the same "far" (XMost or YMost) end, so a change in size means we need to adjust the origin accordingly. That's all this patch does.
13 years ago
Have you tested the patch in left-to-right and right-to-left contexts? The interaction of dir="reverse" with right-to-left layout can be tricky.
I've done some testing, yes. I can't actually get the original bug to appear in a horizontal context (because of the way XUL layout works), which is where this could possibly be relevant. So the testing was necessarily somewhat limited -- I just verified that the layout is correct both with and without the patch.
Comment on attachment 170892 [details] [diff] [review] Proposed patch r+sr=dbaron, but does anyone do things like reposition views for this movement?
Yes, the SetBounds() call handles that. Checked in for 1.8b.