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
The added crashtest still crashes on Android verify runs (TV) for
unknown reasons, so skip it.
Differential Revision: https://phabricator.services.mozilla.com/D16395
--HG--
extra : moz-landing-system : lando
We only ever add a single sheet (EditorOverride.css) there anyway.
Depends on D16282
Differential Revision: https://phabricator.services.mozilla.com/D16283
--HG--
extra : moz-landing-system : lando
Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1348519#c6 and
https://github.com/w3c/csswg-drafts/issues/3201:
Currently grid-template-rows/columns interpolate “per computed value”, which
means that if the number of tracks differs, or any track changes to/from a
particular keyword value to any other value, or if a line name is added/removed
at any position, the entire track listing is interpolated as “discrete”.
But we "agree" with two more granular options:
1. Check interpolation type per track, rather than for the entire list, before
falling back to discrete. I.e. a length-percentage track can animate between
two values while an adjacent auto track flips discretely to min-content.
2. Allow discrete interpolation of line name changes independently of track
sizes.
Besides, for the repeat() function, it's complicated to support interpolation
between different repeat types (i.e. auto-fill, auto-fit) and different repeat
counts, so we always fall-back to discrete if the first parameter of repeat()
is different.
Depends on D16339
Differential Revision: https://phabricator.services.mozilla.com/D16129
--HG--
extra : moz-landing-system : lando
WebRender can handle small image without much overhead. Allowing
small images will give us more predictable behaviour because
we don't end up merging things unneccessarily.
Differential Revision: https://phabricator.services.mozilla.com/D16337
--HG--
extra : moz-landing-system : lando
So that the caller doesn't have to retrieve and compare the previous viewport
offset himself.
Differential Revision: https://phabricator.services.mozilla.com/D15785
--HG--
extra : moz-landing-system : lando
During a "first paint" transaction, compositor-side state such as APZ's copy
of the visual viewport offset is overwritten. However, the scroll frame may
persist on the main thread, and in such a case we want to restore the visual
viewport offset stored in the scroll frame. This comes into play during e.g.
navigation back to a page.
Differential Revision: https://phabricator.services.mozilla.com/D16238
--HG--
extra : moz-landing-system : lando
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando
Now, nobody requires nsIContentIterator interface. So, we can get rid of it.
Unfortunately, there is no macro to keep the inherited class,
ContentSubtreeIterator, in the cycle collection to make it keep managing
ContentSubtreeIterator::mRange without nsISupports interface. Therefore, this
patch moves it into ContentIteratorBase temporarily. Anyway, the following
patch makes those classes not refcountable. At that time, this issue will be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D15927
--HG--
extra : moz-landing-system : lando
Now, all users of ContentSubtreeIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15920
--HG--
extra : moz-landing-system : lando
This mouse click seems superfluous, as window.focus() is called immediately after.
In addition, this click is somehow causing a page up scroll, as it's clicking
a slider frame. This causes the test to fail with scroll anchoring enabled,
for some reason. Removing this click seems to be the easiest solution, as it
doesn't seem intentional.
Differential Revision: https://phabricator.services.mozilla.com/D16276
--HG--
extra : rebase_source : 6e41d587e54d083b0930173d12db1fc180ae70fa
extra : histedit_source : a604e48df440974b7554b6ee8be01641abd92a64
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 fixes a bug that my previous patch uncovers, and that's tested by
css/css-masking/clip/clip-filter-order.html.
We weren't setting up the clips in a way that the clip property clipped filters
and such. This test works in Gecko because Gecko won't draw outside of the
effect bounds, that account for clip().
Differential Revision: https://phabricator.services.mozilla.com/D16232
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando