Commit Graph

9 Commits

Author SHA1 Message Date
Timothy Nikkel
40d6bfabe4 Bug 1150021. Make sure that boxes inside vertical RTL boxes are placed on the right. r=roc
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.
2015-04-07 02:28:57 -05:00
Ryan VanderMeulen
faddf738a4 Backed out changeset d23df90fc306 (bug 1150021) for frequent B2G reftest failures. 2015-04-07 11:27:14 -04:00
Timothy Nikkel
a4d5e18ed1 Bug 1150021. Make sure that boxes inside vertical RTL boxes are placed on the right. r=roc
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.
2015-04-07 02:28:57 -05:00
Stéphane SCHMIDELY
bfd25a67c3 Bug 1144619 - Variable 'nextX' is created in the wrong scope. r=dbaron 2015-03-19 21:00:03 +01:00
Mats Palmgren
e626bbc9a2 Bug 508665 - part 12, Move nsIFrame::GetChildBox/GetNextBox/GetParentBox to XUL where they came from. r=roc 2014-05-24 22:20:41 +00:00
Cameron McCormack
478ce8d3d7 Bug 960848 - Part 1: Make nsFrameState an enum and consolidate all frame state bit definitions in a single preprocessed file. r=dbaron 2014-02-05 12:59:39 +11:00
Robert O'Callahan
11bf1614c4 Bug 945091. Part 3: Flatten layout/xul/base/* into layout/xul. r=glandium 2013-12-04 14:06:16 +13:00
Carsten "Tomcat" Book
f9c1013575 Backed out changeset b5d2afd37164 (bug 945091) for mochitest-8 bustage on a CLOSED TREE 2013-12-04 09:23:39 +01:00
Robert O'Callahan
1fc84c15f4 Bug 945091. Part 3: Flatten layout/xul/base/* into layout/xul. r=glandium 2013-12-04 14:06:16 +13:00