This is a manual subset of changes written with sed, over .h and .cpp
files in layout/.
This also renames a static method on nsSprocketLayout.
Note that nsFlexContainerFrame and nsRangeFrame also have IsHorizontal
methods that are not renamed here, but this can be found to be
relatively safe because none of the IsHorizontal methods are virtual.
MozReview-Commit-ID: Jsdy7I4Q7mX
This is a manual subset of changes written with sed, over .h and .cpp
files in layout/, with additional manual indentation fixes.
MozReview-Commit-ID: weRWGmQLjh
This is a manual subset of changes written with sed, over .h and .cpp
files in layout/. It's a subset because there is also a Selection
method called IsCollapsed, which is not changed here.
MozReview-Commit-ID: 9JgnPv0Hkff
nsSprocketLayout::Layout lays out its children by looping from first child to last child updating local variables x, y as it goes that keep track of the position where to layout the current child.
If the box is horizontal it works left-to-right or right-to-left according to wheather the direction of the box is normal or not. Vertical boxes work similarly top-to-bottom or bottom-to-top. Vertical boxes also respond to CSS direction styles, so that in an LTR box the child boxes are laid out flush left, but flush right in an RTL box. Herein lies the bug, some code assumes the child boxes are laid out flush right in RTL, but the code to actually position the children positions them flush left.
The code that assumes the child are laid out flush right is HandleBoxPack, which determines the origin to start laying out children at, and the code which uses HandleBoxPack to determine if the origin changed during the laying out of the children, and then shifts the children by the amount the origin shifted. The size of our box changing will, in general, change the position of the origin. So the children aren't laid out to the origin that HandleBoxPack expects they will get moved to wrong positions.
nsSprocketLayout::Layout lays out its children by looping from first child to last child updating local variables x, y as it goes that keep track of the position where to layout the current child.
If the box is horizontal it works left-to-right or right-to-left according to wheather the direction of the box is normal or not. Vertical boxes work similarly top-to-bottom or bottom-to-top. Vertical boxes also respond to CSS direction styles, so that in an LTR box the child boxes are laid out flush left, but flush right in an RTL box. Herein lies the bug, some code assumes the child boxes are laid out flush right in RTL, but the code to actually position the children positions them flush left.
The code that assumes the child are laid out flush right is HandleBoxPack, which determines the origin to start laying out children at, and the code which uses HandleBoxPack to determine if the origin changed during the laying out of the children, and then shifts the children by the amount the origin shifted. The size of our box changing will, in general, change the position of the origin. So the children aren't laid out to the origin that HandleBoxPack expects they will get moved to wrong positions.
