There are two mochitests need to be changed. Both of contents have very large
element (5000px, 5000px), to avoid expanding the layout viewport to the large
size we restrict the minimum scale to 1.0 so that we can still check the layout
scroll range.
Also with this minimum scale size usage change, no-zoom-ref.html doesn't render
the horizontal scrollbar on _desktops_ for some reasons (presumably
reftest-async-zoom affects it, and possibly the reasons are the same as bug
1385145 or bug 1269739). Instead of fixing the issue on desktops, I am going to
take a workaround to add explicit minimum-scale value here, it somehow renders
the scrollbar on desktops too.
Note that the reftest added in this commit fails without this fix.
Depends on D18041
Differential Revision: https://phabricator.services.mozilla.com/D18042
--HG--
extra : moz-landing-system : lando
Those reftests assume that the content is automatically zoomed in/out but
unfortunately apz.allow_zooming has set to false on Android since bug 1180267.
With the preference value all of the reftests marked as 'fail' in bug 1504659
now succeed.
Though 1133905-{5,6}-v.html and 1133905-{5,6}-v-rtl.html still fail (they've
been failing before bug 1504659), they will be hopefully fixed in bug 1308702.
Depends on D18038
Differential Revision: https://phabricator.services.mozilla.com/D18041
--HG--
extra : moz-landing-system : lando
The API to create a sticky spatial node doesn't allow us to set a clip
chain that will apply to all the contents of the sticky node. This means
that when the ClipManager sets up the clip state for the sticky node,
the clip chain for it is dropped. Everything still works currently
because the contents of the sticky node have their own clip chains whose
parent link will include the sticky node's clip chain. However, in the
next patch we're going to sever that parent link to fix other issues,
and so we will break this mechanism. This patch fixes it up by
explicitly applying the sticky node's clip chain to the stacking context
that contains all the sticky contents. This ensures all those items pick
up the clip chain.
Differential Revision: https://phabricator.services.mozilla.com/D18100
--HG--
extra : moz-landing-system : lando
The text in the <th> element was causing intermittent fuzz due to
antialiasing. This patch removes the text to eliminate the problem.
Differential Revision: https://phabricator.services.mozilla.com/D18092
--HG--
extra : moz-landing-system : lando
This lets us avoid drawing the complete input for ever tile when
drawing filters into a tile.
Differential Revision: https://phabricator.services.mozilla.com/D17686
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
When some of a border's corners have a border-radius, and that radius
is larger than the sum of the border width and element size, then it
results in the corners of the border overlapping. Webrender draws
borders by rasterizing each segment individually in to the cache, then
compositing them together. In this overlapping case, this has 2
problems:
a) we composite overlapping segments on top of eachother
b) corner segments are not correctly clipped to the curve of the
overlapping adjacent corners
This patch allows corner segments to be clipped by their adjacent
corners. We provide the outer corner position and radii of the
adjacent corners to the border shader, which then applies those clips,
if required, along with the segment's own corner clip when rasterizing
the segment.
As the adjacent corners now affect the result of the cached segment,
they are added to the cache key.
We continue to rasterize the entire segment in to the cache as before,
but now modify the local rect and texel rect of the BrushSegment so
that it only composites the subportion of the corner segment which
does not overlap with the opposite edges of the border.
Differential Revision: https://phabricator.services.mozilla.com/D16872
--HG--
extra : moz-landing-system : lando
CSS visibility doesn't work like `display`. `visibility: visible` elements in a
`visibility: hidden` subtree still get shown.
Differential Revision: https://phabricator.services.mozilla.com/D17068
--HG--
extra : moz-landing-system : lando
This patch changes a few things:
* Restores clipping to the computed clip, but just for SVG filters.
* Computes the clip just from the primitive subregion, not the bounds of the filtered content.
* Unconditionally clips all SVG filters using the primitive subregion
* Allows clips to be combined, if they will be sharing a coordinate space
* Fixes coordinate space of the clip region.
Differential Revision: https://phabricator.services.mozilla.com/D16941
--HG--
extra : moz-landing-system : lando
All of these tests have an .ini file indicating a failure for at least one of
them right now, in the copy that lives in the WPT harness, because
- they trigger a scrollbar in the WPT harness
...and:
- the scrollbar is a slightly different size in the reference case vs.
in one of the testcases, e.g. due to a tiny margin being honored (or not)
on the final piece of content.
This patch shrinks the content a bit in these test files so that they all fit
in a 400x400 viewport and won't trigger a scrollbar. I expect this should make
them pass in the WPT harness when they make the roundtrip through our
synchronization process.
Differential Revision: https://phabricator.services.mozilla.com/D16935
--HG--
extra : moz-landing-system : lando
This patch changes a few things:
* Restores clipping to the computed clip, but just for SVG filters.
* Computes the clip just from the primitive subregion, not the bounds of the filtered content.
* Unconditionally clips all SVG filters using the primitive subregion
* Allows clips to be combined, if they will be sharing a coordinate space
* Fixes coordinate space of the clip region.
Differential Revision: https://phabricator.services.mozilla.com/D16941
--HG--
extra : moz-landing-system : lando
The tests for Bug 1133905 all compare the visibility of scrollbars with
differently-sized css viewports. This patch has some affect on the
viewport sizing that I don't understand, and it causes some of the tests
to start passing and some to start failing.
The test for Bug 1242172 has elements sized to height 100% and checking
for the presence or absence of scrollbars. In this case the patch appears
to increase the css viewport height and decrease the width -- again for
reasons I don't understand -- and this affects the scrollbar sizes.
Differential Revision: https://phabricator.services.mozilla.com/D16078
--HG--
extra : moz-landing-system : lando
The tests for Bug 1133905 all compare the visibility of scrollbars with
differently-sized css viewports. This patch has some affect on the
viewport sizing that I don't understand, and it causes some of the tests
to start passing and some to start failing.
The test for Bug 1242172 has elements sized to height 100% and checking
for the presence or absence of scrollbars. In this case the patch appears
to increase the css viewport height and decrease the width -- again for
reasons I don't understand -- and this affects the scrollbar sizes.
Differential Revision: https://phabricator.services.mozilla.com/D16078
--HG--
extra : moz-landing-system : lando
This patch makes us handle calc with percentages when we can convert to
percentages the same way we handle plain percentages in table layout.
We still treat length + percentage as auto (this matches Blink / WebKit as
well). There's one case we differ with Blink / WebKit, which is calc(% + 0px),
which they'd treat as auto instead of a percentage.
I think this is a bug on them (or at least worth some spec clarification). I
filed https://github.com/w3c/csswg-drafts/issues/3482 for that.
In practice what that'd means for us if the WG decides that Blink / WebKit is
right in that case is that we'd need to keep track of whether the calc()
specifies lengths, and return false from ConvertsToPercent if so.
In any case, nothing that would massively change this patch, and I think enough
of an edge case that is not worth blocking on the CSSWG decision here. Though I
could be convinced otherwise of course.
Differential Revision: https://phabricator.services.mozilla.com/D15719
--HG--
extra : moz-landing-system : lando
The tests for Bug 1133905 all compare the visibility of scrollbars with
differently-sized css viewports. This patch has some affect on the
viewport sizing that I don't understand, and it causes some of the tests
to start passing and some to start failing.
The test for Bug 1242172 has elements sized to height 100% and checking
for the presence or absence of scrollbars. In this case the patch appears
to increase the css viewport height and decrease the width -- again for
reasons I don't understand -- and this affects the scrollbar sizes.
Differential Revision: https://phabricator.services.mozilla.com/D16078
--HG--
extra : moz-landing-system : lando
