'contain:size' just means we should size these elements as if they had no
contents -- i.e. wherever we derive the size of the scrollable frame from the
size of its contents, we should pretend that its contents had zero size.
Differential Revision: https://phabricator.services.mozilla.com/D25155
--HG--
rename : layout/reftests/w3c-css/submitted/contain/contain-size-block-001.html => layout/reftests/w3c-css/submitted/contain/contain-size-block-002.html
rename : layout/reftests/w3c-css/submitted/contain/contain-size-inline-block-001.html => layout/reftests/w3c-css/submitted/contain/contain-size-inline-block-002.html
extra : moz-landing-system : lando
The animated GIF in background-blending-image-color-gif.html has two animation
frames, the one is a red rectangle, the other is a green rectangle. The reftest
is supposed to take the snapshot during the time where the animation frame is
the red rectangle (the first frame) and the frame duration is 1000ms. So if we
take over 1000ms there for some reasons, say on slow platforms, before taking
the snapshot, the reftet fails.
Differential Revision: https://phabricator.services.mozilla.com/D24843
--HG--
extra : moz-landing-system : lando
elementFromPoint-002.html, elementFromPoint-003.html and dialog-showModal.html
use document.elementFromPoint with a given point which is calculated from the
value returned by getBoundingClientRect() for a 100% width element. Before
this change, the given point is outside of view because there is no viewport
meta tag in the documents so that elementFromPoint fails. After this change, the
documents fit to the visual viewport so that elementFromPoint works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D16155
--HG--
extra : moz-landing-system : lando
Relocated the `fuzzy-if` conditions for windows10-aarch64 in the files listed below, as the fuzzy condition was being overridden by conditions that came later.
Also tuned some of the values for pixel differences to reduce oranges.
Differential Revision: https://phabricator.services.mozilla.com/D25113
--HG--
extra : moz-landing-system : lando
The functional fix in this patch series makes some other scrollbar rendering
tests actually test something useful.
Some of them just start passing. Some need a bit of fuzzing. Some need an
adjustment to avoid running afoul of our minimum viewport width of 200.
Differential Revision: https://phabricator.services.mozilla.com/D23079
--HG--
extra : moz-landing-system : lando
On some low end GPUs, clip mask rendering can be a significant
GPU cost. One way to reduce this is to support segment rendering
on more primitive types, to reduce the size of clip masks.
This patch adds support for pictures that have clip masks
to take part in segment rendering. This can significantly
reduce the number of fragments that must be drawn into a clip
mask for off-screen picture surfaces.
In future, WR can take advantage of segment rendering to use
clip mask shaders that handle only a single corner at a time.
This will be a further significant performance win to clip mask
render time.
Differential Revision: https://phabricator.services.mozilla.com/D24852
--HG--
extra : moz-landing-system : lando
If the frame supports it (stacking context + containing block for fixed), and a descendant was
modified, we would have created an override dirty region with just the area of that descendant.
In the case where no descendants are modified, we should use an empty rect, rather than
the area inherited from our parent.
This fixes the case where we forcibly build position:fixed frames (since they might async
scroll differently to the rest of the page), but we only need to build the container item,
not the whole frame subtree within it.
Added a test that shows us building the non-intersecting position:fixed, but not items within it.
Differential Revision: https://phabricator.services.mozilla.com/D23610
--HG--
extra : moz-landing-system : lando
Per spec, "Note: Column boxes do not become the containing block for
elements with position: fixed or position: absolute. The containing
block is the multicol container, it being the principal box."
https://drafts.csswg.org/css-multicol-1/#the-multi-column-model
contentFrame and contentFrameTop are different only if fieldset has
multicol layout. In that case, contentFrameTop is nsColumnSetFrame (or
ColumnSetWrapperFrame after applying Part 2 with
layout.css.column-span.enabled=true).
Differential Revision: https://phabricator.services.mozilla.com/D23617
--HG--
extra : moz-landing-system : lando
If the frame supports it (stacking context + containing block for fixed), and a descendant was
modified, we would have created an override dirty region with just the area of that descendant.
In the case where no descendants are modified, we should use an empty rect, rather than
the area inherited from our parent.
This fixes the case where we forcibly build position:fixed frames (since they might async
scroll differently to the rest of the page), but we only need to build the container item,
not the whole frame subtree within it.
Added a test that shows us building the non-intersecting position:fixed, but not items within it.
Differential Revision: https://phabricator.services.mozilla.com/D23610
--HG--
extra : moz-landing-system : lando
Most rounded rect clips in real content are (a) axis aligned and
(b) have uniform radii.
When these conditions are met, we can run a fast path for clip
mask generation that uses significantly fewer ALU shader ops.
This is not typically a bottleneck on desktop GPUs, but can have
a large performance impact on mobile GPUs (and perhaps low end
integrated GPUs).
The Mali shader analyzer reports the slow path for the rounded
rect clip shader to be 94 cycles per fragment, while the fast
path is 10 cycles.
Differential Revision: https://phabricator.services.mozilla.com/D23817
--HG--
extra : moz-landing-system : lando
Most rounded rect clips in real content are (a) axis aligned and
(b) have uniform radii.
When these conditions are met, we can run a fast path for clip
mask generation that uses significantly fewer ALU shader ops.
This is not typically a bottleneck on desktop GPUs, but can have
a large performance impact on mobile GPUs (and perhaps low end
integrated GPUs).
The Mali shader analyzer reports the slow path for the rounded
rect clip shader to be 94 cycles per fragment, while the fast
path is 10 cycles.
Differential Revision: https://phabricator.services.mozilla.com/D23817
--HG--
extra : moz-landing-system : lando
If the frame supports it (stacking context + containing block for fixed), and a descendant was
modified, we would have created an override dirty region with just the area of that descendant.
In the case where no descendants are modified, we should use an empty rect, rather than
the area inherited from our parent.
This fixes the case where we forcibly build position:fixed frames (since they might async
scroll differently to the rest of the page), but we only need to build the container item,
not the whole frame subtree within it.
Added a test that shows us building the non-intersecting position:fixed, but not items within it.
Differential Revision: https://phabricator.services.mozilla.com/D23610
--HG--
extra : moz-landing-system : lando
It's not very easy to understand on its current state, and it causes subtle bugs
like bug 1533654.
It could be simpler if we centralized where the interactions between properties
are handled. This patch does this.
This patch also changes how MathML script sizes are tracked when scriptlevel
changes and they have relative fonts in between.
With this patch, any explicitly specified font-size is treated the same (being a
scriptlevel boundary), regardless of whether it's either an absolute size, a
relative size, or a wide keyword.
Relative lengths always resolve relative to the constrained size, which allows
us to avoid the double font-size computation, and not give up on sanity with
keyword font-sizes.
I think given no other browser supports scriptlevel it seems like the right
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D23070
--HG--
extra : moz-landing-system : lando
They were revised in bug 1158392 to work with containerless scrolling and
not with container scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D22744
--HG--
extra : moz-landing-system : lando