With APZ, we always layerize the first scrollable element of the page,
if the page itself is not scrollable. These additional layers can cause
fuzzy reftest failures in two ways: differences in blending, and by
disabling sub-pixel test anti-aliasing. The latter is only a problem
with unaccelerated drawing, because we don't support component alpha
layers with BasicLayers. (We also don't support them with
BasicCompositor, but "Reftest unaccelerated" only tests BasicLayers).
The test in question sets up an inconsistent state for desktop platforms because
it intends to simulate what the APZ does, but does it only partially. The APZ
code would set a CSS viewport (which the test does) but it doesn't set the
scroll-position-clamping-scroll-port-size which the APZ would always do.
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.
Note that this replaces the code that allows eroding the space with new
code that reduces the focusPadding value.
(Also, we previously didn't count the focusPadding towards what could be
eroded, which meant we wouldn't quite get to the edge of the padding and
border, because we weren't counting the extra for the focusPadding.)
The existing reftests that I'm changing from == to != are ones that were
specifically testing issues related to erosion of padding.
The change to 491180-{1,2}-ref.html is because we now *do* erode the
focusPadding, which is 3px in the horizontal dimensions (see the
button::-moz-focus-inner styles in forms.css), and that was the only
nonzero style on the button in 491180-{1,2}.html.
CLOSED TREE (per RyanVM)
Note that this replaces the code that allows eroding the space with new
code that reduces the focusPadding value.
(Also, we previously didn't count the focusPadding towards what could be
eroded, which meant we wouldn't quite get to the edge of the padding and
border, because we weren't counting the extra for the focusPadding.)
The existing reftests that I'm changing from == to != are ones that were
specifically testing issues related to erosion of padding.
The change to 491180-{1,2}-ref.html is because we now *do* erode the
focusPadding, which is 3px in the horizontal dimensions (see the
button::-moz-focus-inner styles in forms.css), and that was the only
nonzero style on the button in 491180-{1,2}.html.
Note that this replaces the code that allows eroding the space with new
code that reduces the focusPadding value.
(Also, we previously didn't count the focusPadding towards what could be
eroded, which meant we wouldn't quite get to the edge of the padding and
border, because we weren't counting the extra for the focusPadding.)
The existing reftests that I'm changing from == to != are ones that were
specifically testing issues related to erosion of padding.
The change to 491180-{1,2}-ref.html is because we now *do* erode the
focusPadding, which is 3px in the horizontal dimensions (see the
button::-moz-focus-inner styles in forms.css), and that was the only
nonzero style on the button in 491180-{1,2}.html.
The optimization that allows opacity items that only contain one item (which can fold the opacity into it's own drawing) to flatten away will never apply when we have layer event region items. This is because opacity generates a stacking context and we always push a new layer event regions item for a stacking context. So if we want to keep this optimization we need to extend to to at least two items. Layer event regions items have empty bounds, which allows the non-overlapping test to pass for layer event region items. Although it will work with any non-overlapping items.
When choosing a painted layer for the event region item we must report the bounds of the hit regions as the bounds so that we don't fall through to the bottom most painted layer.
Sometimes, in very specific cases, the visible region gets simplified to one rect and is thus much bigger than the draw region. This becomes a problem if we decide to pull an opaque background color from a lower layer so that we are opaque. In which case we draw the background color over the whole visible region. But we use the draw region to determine if we can place items below this layer, so that background color could cover them incorrectly.
This adjusts existing reftest annotations for tests that fail on 10.8
that are showing up as failing on 10.10 as well to be marked using >=
version tests rather than == version tests.
The function IsSubjectToAsyncTransforms() was not correctly reporting when a
layer was actually subject to async transforms. As a result, sometimes display
items from above such a layer would end up in a layer below. This could
manifest as page elements being improperly covered by async scrolling elements.
David Anderson
Mason Chang
Simon Montagu
Timothy Nikkel
Jonathan Kew
Kartikaya Gupta
Markus Stange
Phil Ringnalda
Ryan VanderMeulen
Alexandre Lissy
Carsten "Tomcat" Book
Geoff Brown
Wes Kocher
L. David Baron
Daniel Holbert
Chris Lord
Aaron Klotz
Mike Taylor
Seth Fowler
Robert O'Callahan
Tom Schuster
Ms2ger
Benoit Girard
Ethan Lin
Mats Palmgren
Jonathan Watt