For Android we want to be able to set a global zoom factor that will scale any page where font inflation is not turned on.
Android makes the system font scale available as a float factor. For our purposes, converting this to a percentage based value and rounding to an integer is accurate enough and enables us to pass this value as a standard Gecko int preference. This means we can make use of the standard infrastructure for setting and retrieving Gecko-side preferences both from Java and JS (the latter during testing), as opposed to having to write custom JNI and C++/IDL helper functions.
To that effect, we implement a method for retrieving that setting via nsLayoutUtils, analogous to the current font inflation settings. Since we later want to clamp the effective text zoom resulting from that setting by zoom.minPercent and maxPercent, we add var caches for them in nsLayoutUtils as well.
MozReview-Commit-ID: Ler2YmwzImE
If we disable APZ on an individual scrollable element by setting the "disable APZ"
flag on the ScrollMetadata, we should also disable paint-skipping for that element.
If we don't do this, we end up in a situation where the APZ code is not applying
the async transform but is sending repaint requests expecting the main thread to
do repaints. Meanwhile the main-thread thinks that it can send empty transactions
and have APZ update the async transform (a.k.a. paint-skipping). So visually
neither APZ nor main-thread have an effect and the element doesn't appear to
scroll except with the tile-aligned displayport shifts. Disabling paint-skipping
on the element fixes the issue.
MozReview-Commit-ID: H4wpVLw8r8X
Each concrete class of imgIContainer is able to handle opacity already. All we
need to do is pass opacity value to them.
MozReview-Commit-ID: EMkLnG3YXA1
Each concrete class of imgIContainer is able to handle opacity already. All we
need to do is pass opacity value to them.
MozReview-Commit-ID: EMkLnG3YXA1
I think there are three advantages of this change:
1. removes some dependencies from layout / painting code to pre-computed
value stuff in the style system;
2. makes it easier to audit usage of specific fields in style structs
(which is probably a side effect of the first one);
3. potentially improves performance since it doesn't go through the
unnecessary general logic in ExtractComputedValue.
Also, combined with the part before, we get a unified list for visited-
dependent properties so that we can ensure the assertion here and the
style difference calc code are consistent.
MozReview-Commit-ID: 5B9aN7CfRgI
Simply move ComputeHTMLReferenceRect and ComputeSVGReferenceRect from
nsCSSClipPathInstance to nsLayoutUtils to reuse the code in both clip-path and
mask.
MozReview-Commit-ID: 59LofAeEhKQ
This patch is written with the help of the following script.
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "css::Side" "Side"
MozReview-Commit-ID: DPV6vivpPUp
Expose requestIdleCallback on Window and implement running callbacks
in idle periods by posting rICs to the main threads idle queue.
MozReview-Commit-ID: KSYQsyaZ6is
Expose requestIdleCallback on Window and implement running callbacks
in idle periods by posting rICs to the main threads idle queue.
MozReview-Commit-ID: KSYQsyaZ6is
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
Note about no-stacking-context-(opacity|transform)-removing-animation-in-delay.html
Before this patch we don't create any stacking context for animations overridden
by !important rules, but after this patch we do create a stacking context for
such animations. As a result, in the test case we did paint a stacking context
in the first rAF callback and then in the second rAF callback we did clear the
painted stacking context. Unfortunately sometimes the second rAF callback was
called prior to clear the stacking context on the compositor because of
compositor delay. To avoid this situation, we have to wait for MozAfterPaint
instead of rAF callback.
MozReview-Commit-ID: AG1Y0IgoB3U
