This reverts some of the changes made in bug 823483 patch 3 because it
turns out we don't want all of that behavior change.
MozReview-Commit-ID: Lbpi762qsbM
This restores the quirky behavior for text inputs, which was removed by
patch 2, but only halfway (for width but not max-width), which matches
Chromium and Edge.
--HG--
extra : commitid : 7uk3XdYc1LC
This reduces the set of elements to which this quirky behavior applies.
This matches the behavior of Chromium and Edge.
--HG--
extra : commitid : 9qz7ODJhNzS
This changes nsDisplayImage::GetDestRect and nsImageFrame::PredictedDestRect to return
the true dest rect of the image, without intersecting it with the image content box.
The only caller of these functions that actually requires a rectangle that's within
the image's content bounds is nsDisplayImage::GetOpaqueRegion, so I'm changing that
to intersect with the display item's bounds.
I'm pretty sure nsImageFrame::MaybeDecodeForPredictedSize() also prefers the unclipped
dest rect, because it cares about the scale at which the image is painted, and not
about which parts of the image are painted.
--HG--
extra : commitid : CDJJnfN7vF3
extra : rebase_source : 5b59f81ab60290f508b83db7e942559da621cb70
This fixes the bug because it prevents a cache conditions check for a
later PeekStyle* in nsStyleContext::CalcStyleDifference from computing a
struct that was null when we checked it earlier in CalcStyleDifference.
This, in turn, could allow the old context to be retained (and
reparented to the new parent) even though it now has incorrect data in
the font or visibility struct that was computed while checking the
conditions for another struct.
This should also improve performance in some cases of style changes on
not-yet-presented frames because we have fewer change hints to process.
--HG--
extra : commitid : 16o8oS0RLfx
The change to the 427129-table-caption test was just to make the
reference match the test.
The change to the other 427129 tests was duplicating the test that
failed, adjusting the reference for one version of it (no longer pushed
down), and testing an alternative pushed-down case for the other
version.
It's not clear to me how to test that that
1062963-floatmanager-reflow.html still tests what it originally tested,
given the code change that's happened since.
--HG--
extra : commitid : 178ok0G1NFo
This adds an additional retry loop in block reflow that we can only
trigger when reflowing a block formatting context (replacedBlock
non-null). It can retry in two different ways, either with a narrower
width but at the same vertical position (when
ReplacedBlockFitsInAvailSpace is still true) or at a new vertical
position (which is treated as a form of clearance).
Fortunately we don't have to worry about margins collapsing *through*
such a boundary since we're dealing with a new block formatting context.
Note that Chromium passes all of the new bfc-displace-* tests, although
it moves the block formating context down unnecessarily in
bfc-shrink-1.html (which we do neither before nor after the patch),
though agrees with the width we have after the patch (but not before the
patch).
--HG--
extra : commitid : FgDc4hjTxHp
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.
Geoff Brown
Ryan VanderMeulen
Mason Chang
Sebastian Hengst
Shing Lyu
L. David Baron
Jeremy Chen
Bas Schouten
Nicolas Silva
Xidorn Quan
Kartikaya Gupta
Jonathan Griffin
Joel Maher
Cameron McCormack
Markus Stange
Carsten "Tomcat" Book
Boris Zbarsky
Mats Palmgren
Phil Ringnalda
Robert O'Callahan
Thinker K.F. Li
Matt Woodrow
Andrew Comminos
Kearwood (Kip) Gilbert
John Daggett
Justin Wood
Jonathan Kew
Wes Kocher
Lee Salzman
Masatoshi Kimura
Timothy Nikkel
Mark Capella
David Anderson
Simon Montagu
Alexandre Lissy
Daniel Holbert
Chris Lord
Aaron Klotz
Mike Taylor
Seth Fowler