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
Collapsing thumb causes frame of scrollbar to cache an incorrect pref
size, which makes it not able to appear in certain cases.
This patch changes it to use "visibility: hidden" instead so that the
thumb is hidden but still contributes to the width of scrollbar.
An alternative would be also change the code in nsScrollbarFrame to set
something other than collapsed attribute instead, but I'm not sure
whether doing that is any better than just adding a rule. We need the
rule anyway regardless of what we set on the element.
Differential Revision: https://phabricator.services.mozilla.com/D15244
--HG--
extra : moz-landing-system : lando
This Make nsSVGIntegrationUtils::AdjustInvalidAreaForSVGEffects return the
original area if there are no filter effects (instead of using some bogus
fallback code).
Differential Revision: https://phabricator.services.mozilla.com/D16516
--HG--
extra : rebase_source : 16de5f99068e5c219f4f366af848ae3cc6c83417
extra : amend_source : 62f0d870192421a58bbf6f7f083c6614c936ac3b
It was enabled by default in bug 1041833 (for desktops) and
bug 1087562 (for Fennect).
Depends on D15706
Differential Revision: https://phabricator.services.mozilla.com/D15707
--HG--
extra : moz-landing-system : lando
1. Test the most simple cases when we use max-content/min-content on
width/height/block-size.
* block-size-with-min-or-max-content-1a.html
* block-size-with-min-or-max-content-1b.html
2. Test base cases when we use max-content/min-content on
width/height/block-size inside the table element.
* block-size-with-min-or-max-content-table-1a.html
* block-size-with-min-or-max-content-table-1b.html
3. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}{height|width} and {min-|max-}block-size on the inner element.
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-1.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-1.html
4. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}{height|width} on the outer element (i.e. the container).
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
5. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}block-size on the outer element (i.e. the container).
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html
Depends on D14320
Differential Revision: https://phabricator.services.mozilla.com/D13485
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
