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
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.
MozReview-Commit-ID: AG1Y0IgoB3U
KeyframeEffectReadOnly::HasAnimationOfProperty() calls GetAnimationOfProperty()
which checks mWinsInCascade flag and the mWinsInCascade flag is set to true
only if the effect is in-effect.
That means nsLayoutUtils::HasCurrentAnimationOfProperty() actually represents
that a given frame has at least one animation which is current and *in-effect*
(i.e. active).
MozReview-Commit-ID: 93rMMmzrBMi
--HG--
extra : rebase_source : c48167d874aa243ab070d0aa64876307748e3493
After using enum class, a switch-case warning in CombineBreakType is caught.
This is one of such kind safty checks that we would like to gain.
Fix it by adding default case for switch-case in CombineBreakType.
MozReview-Commit-ID: BdS3LPN6qzX
--HG--
extra : rebase_source : 17f24a0d482ed6eb51b23e6942d0ac1c87375e0b
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The modification to nsAbsoluteContainingBlock.h and nsBlockFrame.cpp are
needed to fix the build error due to the file order changed in the unified
build.
The #includes are fixed by 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 "nsHTMLReflowMetrics\.h" "mozilla\/ReflowOutput\.h"
MozReview-Commit-ID: KWvcG3UtKNn
--HG--
rename : layout/generic/nsHTMLReflowMetrics.cpp => layout/generic/ReflowOutput.cpp
rename : layout/generic/nsHTMLReflowMetrics.h => layout/generic/ReflowOutput.h
extra : rebase_source : dc62fb3ad4d95e732e5985c7ab9f757a0e23abcb
This preference was added in bug 747274, and the need for it (i.e.,
having it default to a different value on Android) was removed a few
weeks later in bug 750598.
Whether we honor the preference depends on which drawing function we go
through, which bug 720531 will make even more inconsistent than it
already is (by causing it to be honored for border-image-repeat: space,
but not other values of border-image-repeat).
Rather than trying to clean it up, it seems best to remove it, since its
initial purpose appears to have been having a different default on
Android, which we longer need.
MozReview-Commit-ID: IFW2Ukwx4fH
--HG--
extra : transplant_source : q1%22Ad%D2%AF%8E%E5%E2%257C%A3%9F%95%DB%A5%92%B2
We want to know that an nsIFrame has a transform or opacity animations
regardless of its state, e.g., running on the main-thead, paused or
finished but in fill:forwards state, to create a stacking context
for the animation.
MozReview-Commit-ID: mNYsd5RO3u
--HG--
extra : rebase_source : 19f88d9f77f3c329f36a6505c6335bae64050a22
The function doesn't need to be a non-static member of nsIPresShell: it only checks if the document of the passed in element matches the presshell's document, and then the remaining code could be static. It has only one user, nsDocumentViewer::FindContainerView, and it doesn't care about the specific presshell, it just wants the primary frame, so it doesn't need the document check.
This lets us simplify nsDocumentViewer::FindContainerView because it had to jump through hoops to get the presshell.
The function doesn't need to be a non-static member of nsIPresShell: it only checks if the document of the passed in element matches the presshell's document, and then the remaining code could be static. It has only one user, nsDocumentViewer::FindContainerView, and it doesn't care about the specific presshell, it just wants the primary frame, so it doesn't need the document check.
This lets us simplify nsDocumentViewer::FindContainerView because it had to jump through hoops to get the presshell.
nsLayoutUtils::IsRectVisibleInScrollFrames() was used only by
SelectionCarets which was removed in bug 1221459.
MozReview-Commit-ID: 4dQAq1umHY7
--HG--
extra : rebase_source : 9c35effc9ac44bb9de5df1e4ddfc0d32edcfb9c9
It's not obvious that it does this (unless you read the comment or the code), and we don't gain much by doing it.
Also we need to split it up for the next patch in this bug.
Without this patch, patch 2 will cause assertions since
nsFrame::DestroyFrom calls nsFrame::HasCSSAnimations (at a time when the
child frame has been destroyed), which calls into the code modified in
patch 2 to call GetStyleFrame.
--HG--
extra : commitid : EkhtcNIf7ye
Temporarily rename GetDisplayPort to GetDisplayPortRelativeToScrollPort for the duration of this patchset.
This means that every caller of GetDisplayPort is guaranteed to be touched by this patchset (assuming it compiles), and thus each call site can be checked in review to make sure it is relative to the correct coordinate system.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name GetOrMaybeCreateDisplayPort.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name ViewportHasDisplayPort.
This makes it clearer whether we're just checking if a displayport exists,
or we're actually consuming its value.
--HG--
extra : source : 70bb222e860669a6cf6e803dbd57f088ca4fbc04
AutoTextRun now only needs a DrawTarget instead of an nsRenderingContext, and
similar nsRenderingContext/gfxContext-to-DrawTarget replacements can be
propagated a long way up the call graph. This patch replaces 93 occurrences of
nsRenderingContext and 135 occurrences of gfxContext with DrawTarget; that's
13% of them.
The patch is mostly plumbing changes. A couple of not-entirely-plumbing
changes:
- It adds a comment about the null check in
gfxGlyphExtents::GetTightGlyphExtentsAppUnits().
- A couple of functions simply had an unused gfxContext or nsRenderingContext
parameter removed, e.g. SetLineBreaks().
--HG--
extra : rebase_source : 8f56994bb4d254a86788b17ab2864ebc758a7e6b
The two flags combined used to be represented by just RENDER_IGNORE_VIEWPORT_SCROLLING. Until http://hg.mozilla.org/mozilla-central/rev/99279c1c33cc (bug 590294) split RENDER_DOCUMENT_RELATIVE out. It split out the requested rect to be document relative. But it also split out the part about "drawing the document as if it had not been scrolled" with the new flag, but the comments for that part didn't get updated.
The names of the flags are perhaps inaccurate, but changing that requires changing a lot more code.
We may want to do this for fixed pos frames in all documents (not just root documents). However, this patch only maintains the previous behaviour on purpose.
Instead of returning the root scroll frame if we encountered the root frame (which is the parent of the root scroll frame).
This allows the use of GetNearestScrollableFrame to walk up the frame tree without getting into a infinite loop going from root scroll frame to root frame and back.
This regresses bug 1105823 in that fixed pos frames will no longer find the root scroll frame of their document. The next patch will fix that.
The only other type of frame that will be affected when calling GetNearestScrollableFrame are viewport (root) frames. However, the only user of SCROLLABLE_ALWAYS_MATCH_ROOT (APZCCallbackHelper) calls GetNearestScrollableFrame on the result of a hit test on a display list. Viewport frames never create any display items whose HitTest function could return the viewport frame.
Removing the "stop at ancestor" parameter from functions that compute AGR meant that nsLayoutUtils::GetAnimatedGeometryRootFor could no longer pass the display item's reference frame as the "stop at ancestor" which meant that the AGR could cross the reference frame for the item, which we don't want. So we make transformed frames into AGRs.
This makes the computation of display items whose frames are transformed tricky. We need the AGR of the transform item to be the ancestor AGR, not the underlying frame of the transform item (which is now an AGR). So we modify nsLayoutUtils::GetAnimatedGeometryRootFor to handle this. (The patch from bug 1205087 didn't suffer from this problem because it special cased the computation of the AGR of transform items. Leaving anybody who called nsLayoutUtils::GetAnimatedGeometryRootFor to get the wrong result.)
The computation of the AGR for scroll metadata in ContainerState::ProcessDisplayItems specifically bypassed nsLayoutUtils::GetAnimatedGeometryRootFor to avoid it's special processing of fixed background items. However we do want the AGR for scroll metadata to do this special processing of transform items. So we add a flag to bypass the fixed background behaviour and use it for the scroll metadata AGR.
Hiroyuki Ikezoe
Phil Ringnalda
Mats Palmgren
Jeremy Chen
Jonathan Chan
Gregory Szorc
Cameron McCormack
Ting-Yu Lin
L. David Baron
Kartikaya Gupta
Astley Chen
Jonathan Watt
Matt Woodrow
Xidorn Quan
Ethan Lin
Carsten "Tomcat" Book
Seth Fowler
Botond Ballo
CJKu
Kyle Huey
Timothy Nikkel
Xidorn Quan
Robert O'Callahan
Benoit Girard
Wes Kocher
Boris Chiou
Randall Barker
Nicholas Nethercote
Morris Tseng
Lee Salzman
Brian Birtles
Jeff Gilbert
Mason Chang
Tobias Schneider