Typically we set the NS_FRAME_MAY_BE_TRANSFORMED bit on a frame when one of the
following situations arises:
a. We update the keyframes of a KeyframeEffect to include transforms or we
create a new KeyframeEffect that animates transforms (in
KeyframeEffect::SetKeyframes), or
b. We retarget a KeyframeEffect with transforms at a new element (in
KeyframeEffect::SetTarget), or
c. We create an nsFrame with transform animations applied to it (in
nsFrame::Init), or
d. We get a nsChangeHint_AddOrRemoveTransform hint in
RestyleManager::ProcessRestyledFrames and decide to update the frame bit on
the frame and its continuations accordingly.
However, there are some situations where we can have a transform animation on
a frame where none of the above are triggered.
For example, if the style frame is not unavailable (e.g. a display:none
element) when the KeyframeEffect is initialized we will fail to the frame bit in
(a) and if we never retarget the effect we will never set reach (b).
Furthermore, if we have an animation that is "not relevant" (e.g. idle) and
hence not registered with the EffectSet when the frame is initialized we will
fail to set the frame bit in (c).
Finally, if the the animation does not produce a style change that causes the
nsChangeHint_AddOrRemoveTransform bit to be set (e.g. the transform animation
begins at 'none') we will not set the frame bit in (d).
As a result, we can end up failing to set the NS_FRAME_MAY_BE_TRANSFORMED bit
for some content.
The crashtest included in this patch produces such a case and, without the code
changes in this patch, will fail the assertion in ApplyRenderingChangeToTree[1]:
NS_ASSERTION(!(aChange & nsChangeHint_UpdateTransformLayer) ||
aFrame->IsTransformed() ||
aFrame->StyleDisplay()->HasTransformStyle(),
"Unexpected UpdateTransformLayer hint");
That is because although the nsChangeHint_UpdateTransformLayer bit will be set,
aFrame->IsTransformed() will return false because the frame bit has not been
set, and aFrame->StyleDisplay()->HasTransformStyle() will return false because
the animation sets the transform to 'none'.
Not only will this assertion fail, but once we cease flushing style as part of
triggering an animation later in this patch, the reftest
layout/reftests/web-animations/stacking-context-transform-changing-effect.html
will begin to fail. That reftest produces a similar situation to the crashtest
but it currently does not fail because the style flush that happens as part of
creating an animation ensures the style frame is available at the point when the
animation is triggered and hence case (a) from above is hit.
This patch addresses this by detecting the case where we have this change hint
set but not the corresponding frame bit, and setting the frame bit.
[1] https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/layout/base/RestyleManager.cpp#1191-1199
Differential Revision: https://phabricator.services.mozilla.com/D18911
--HG--
extra : moz-landing-system : lando
After this I can pass the document from the caller to ResolveSameStructsAs, and
get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
After this I can pass the document from the caller to
ResolveSameStructsAs, and get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
This patch should make the detection of whether we should reframe in
UpdateContainingBlock exact.
It should have no behavior change, but sometimes reframing can confuse event
handling code or what not.
We don't have a reduced test-case for the event handling regression this fixes,
but I added a test to ensure we don't uselessly reframe in this case that fails
without this patch and passes with.
Differential Revision: https://phabricator.services.mozilla.com/D16333
--HG--
extra : moz-landing-system : lando
We currently perform anchor adjustment in three spots:
1. If the target of RestyleManager::RecomputePosition is in a scroll anchor chain
2. If the reflow root is in a scroll anchor chain
3. In nsHTMLScrollFrame::DidReflow, for itself
It looks like it's possible for a scroll anchor container to be adjusted by (1)
and (2 or 3) in the same PresShell flush.
This should be okay, except that we consume mSuppressAnchorAdjustment when
performing an adjustment, and this can lead us to miss the second time that
we perform adjustments in a PresShell flush.
This commit reworks how we run anchor adjustments so that we collect all
scroll anchor containers that should be adjusted, and only perform the
adjustments once.
Differential Revision: https://phabricator.services.mozilla.com/D16407
--HG--
extra : source : cbdbd08379d99f9d55f756c57d728c28331be5da
This commit implements the second half of the heuristics to detect style changes
that could lead to feedback loops with scroll anchoring. [1]
A new change hint is added for when a style is changed from positioned to not
positioned. When this hint is applied, scroll anchor suppression is triggered in
the scroll anchor container where the frame used to be, and the new scroll
anchor container where the frame is added after reconstruction.
[1] https://drafts.csswg.org/css-scroll-anchoring/#suppression-triggers
Differential Revision: https://phabricator.services.mozilla.com/D13273
--HG--
extra : rebase_source : 085c7d6b62c3f52122d9ae57eded71a1de2527a1
extra : source : e76b842c7b7fbdf434de7f099e399a8a53753493
This commit implements anchor offset adjustment. When the position of a frame
that is an anchor is changed during reflow, we notify the anchor container. The
anchor container will then post a reflow callback.
Then when reflow is completed, the anchor container will perform a scroll to
keep the anchor node in the same relative position.
Differential Revision: https://phabricator.services.mozilla.com/D13270
--HG--
extra : rebase_source : 9d40a5d5b73777d0da3799f162eeb85bb8e6d8f0
extra : source : d9052f7b34d9857863b66d64797f8b0b82504bec
This commit adds a mechanism for scroll anchor containers to request an anchor
node selection at a future time. Currently this is before styling so that anchor
adjustment suppression will have current anchor nodes.
Differential Revision: https://phabricator.services.mozilla.com/D13269
--HG--
extra : rebase_source : 7af2dcc7953e446eb993625fa7ff32aa5a141eab
extra : source : e7124fecb7215769a5404c5f2268bbe715162393
This commit implements the second half of the heuristics to detect style changes
that could lead to feedback loops with scroll anchoring. [1]
A new change hint is added for when a style is changed from positioned to not
positioned. When this hint is applied, scroll anchor suppression is triggered in
the scroll anchor container where the frame used to be, and the new scroll
anchor container where the frame is added after reconstruction.
[1] https://drafts.csswg.org/css-scroll-anchoring/#suppression-triggers
Differential Revision: https://phabricator.services.mozilla.com/D13273
--HG--
extra : rebase_source : e623d8526ccfbc257b15e272f8ff428171ec151b
extra : histedit_source : d5538cea7417d1c13c4f072daee722bcd9b11713
This commit implements anchor offset adjustment. When the position of a frame
that is an anchor is changed during reflow, we notify the anchor container. The
anchor container will then post a reflow callback.
Then when reflow is completed, the anchor container will perform a scroll to
keep the anchor node in the same relative position.
Differential Revision: https://phabricator.services.mozilla.com/D13270
--HG--
extra : rebase_source : 44797fcf6585d5912f83baea90a8e554f39618b5
extra : histedit_source : c4354ba8aac99e0d083f40b515369db6a95f997d
This commit adds a mechanism for scroll anchor containers to request an anchor
node selection at a future time. Currently this is before styling so that anchor
adjustment suppression will have current anchor nodes.
Differential Revision: https://phabricator.services.mozilla.com/D13269
--HG--
extra : rebase_source : ba621678b697847e59203444d7b6b0e737742675
extra : histedit_source : b0c6f8642a01bd8ded312d0fa27eecd55c4422a9
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
So we do it while we're still handling re-entrant changes for SVG, since SVG can
post change hints from UpdateOverflow().
Differential Revision: https://phabricator.services.mozilla.com/D12102
--HG--
extra : moz-landing-system : lando
All of the removed includes are redundant (i.e. they're #included elsewhere in
the same file).
In most cases, I'm removing the second (redundant) copy of the
#include, except when that copy makes more sense (i.e. if it's in better sorted
order, or if it's paired alongside a closely-associated header while the
earlier copy is not).
Here's the script that I used to generate candidates here -- I ran this in
every subdirectory of layout, on my linux machine (warning, this writes two
files to your /tmp directory):
for FILE in *.h *.cpp; do
nonunique=$(grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | wc -l)
unique=$( grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq | wc -l)
if [[ "$unique" != "$nonunique" ]]; then
echo "$FILE: $nonunique / $unique"
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort > /tmp/nonunique.txt
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq > /tmp/unique.txt
diff /tmp/nonunique.txt /tmp/unique.txt
echo
fi
done
Depends on D13773
Differential Revision: https://phabricator.services.mozilla.com/D13774
--HG--
extra : moz-landing-system : lando
Just adding:
- a missing-but-needed forward-decl (in LayersLogging.h which is
included by files in layout/base).
- a 'using' decl (to provide layers::AnimationInfo).
- a missing-but-needed #include for nsCOMPtr.
Differential Revision: https://phabricator.services.mozilla.com/D12964
--HG--
extra : moz-landing-system : lando
Bug 828240 switched the children only transform on an outer svg from applying to
each of the anonymous child's children to applying directly to the anonymous
child instead. So now when the viewBox changes on an outer svg, we need to
update (just) the overflow of the anonymous child. The children only transform
on an inner svg still applies to the children of the inner svg, so we continue
updating those children in that case.
Hit testing uses overflows as part of the testing process, so was broken by the
lack of overflow updates.
Differential Revision: https://phabricator.services.mozilla.com/D5668
--HG--
extra : moz-landing-system : lando
This is just an optimization regardless of the fix improper change hint
generated by blocked animations.
Differential Revision: https://phabricator.services.mozilla.com/D12366
--HG--
extra : moz-landing-system : lando
Bug 828240 switched the children only transform from applying to each of the
anonymous child's children to applying directly to the anonymous child instead.
So now when the viewBox changes, we need to update (just) the overflow of the
anonymous child, where previously we were updating the overflows of each of the
children (which was having no effect I guess, since they no longer have the
child only transform applied to them).
Hit testing checks for hits using overflow, so was broken by the lack of
overflow update on the anonymous child (combined with the fact that the
anonymous child is now transformed by the children only transform).
Differential Revision: https://phabricator.services.mozilla.com/D5668
--HG--
extra : moz-landing-system : lando
If a frame cannot be repositioned, the reflow request should hint at the
position change, so that if that frame is a reflow root, the next reflow won't
just start from there and not set the new position.
Updated incorrect comment about nsChangeHint_ReflowChangesSizeOrPosition
always requiring nsChangeHint_ClearAncestorIntrinsics.
Differential Revision: https://phabricator.services.mozilla.com/D9065
--HG--
extra : moz-landing-system : lando
This change eliminates
- nsLayoutUtils::LastContinuationOrIBSplitSibling calls for each CSS
properties on WebRender
- iterating over each display item for each compositor runnable CSS properties
- a bunch of stuff in the case where the layer manager has not yet created,
i.e. the compositor thread is not ready to receive animations
Depends on D11425
Differential Revision: https://phabricator.services.mozilla.com/D11426
--HG--
extra : moz-landing-system : lando
This change gets all effective CSS properties on an nsIFrame just once.
Note that LayerAnimationInfo::GetCSSPropertiesFor intentionally returns
nsCSSPropertyIDSet instead of nsCSSPropertyID since when we support individual
transform properties for the compositor the mapping between display item types
and nsCSSProperty has to be 1:N. E.g. all scale/translate/rotate properties are
mapped to transform display item.
Depends on D11424
Differential Revision: https://phabricator.services.mozilla.com/D11425
--HG--
extra : moz-landing-system : lando
The major change in this patch is ::-moz-column-span-wrapper blocks are no
longer linked into the continuation chains when they're created in
CreateColumnSpanSiblings(). We can do that because
::-moz-column-span-wrapper is an non-inheriting anon box, which doesn't need
to be restyled.
This prevents RestyleManager::ProcessPostTraversal or
nsIFrame::UpdateStyleOfOwnedChildFrame, which set the same style on all
continuations of the frame they are working with, from overriding the
::-moz-column-span-wrapper style.
GetNextContinuationWithSameStyle was deleted in bug 1447367. Delete the comment
in nsInlineFrame::UpdateStyleOfOwnedAnonBoxesForIBSplit() to avoid confusion.
This patch also adds another condition to reframe the multi-column container
in MaybeRecreateContainerForFrameRemoval(). That condition is when an
element has a "column-span:all" descendant, i.e. the element's frame has
"column-span:all" siblings (which is created by CreateColumnSpanSiblings).
The added test multicol-span-all-dynamic-remove-006.html will fail without
this patch.
Depends on D5212
Differential Revision: https://phabricator.services.mozilla.com/D9988
--HG--
extra : moz-landing-system : lando
In the case of WebRender there is no layers, but actually we'd been using it for
WebRender too, that's confusing.
Depends on D10689
Differential Revision: https://phabricator.services.mozilla.com/D10690
--HG--
extra : moz-landing-system : lando
In the case of WebRender there is no layers, but actually we'd been using it for
WebRender too, that's confusing.
Depends on D10689
Differential Revision: https://phabricator.services.mozilla.com/D10690
--HG--
extra : moz-landing-system : lando
Prepare for scrollbar-width which should trigger the same kind of change.
MozReview-Commit-ID: 1n9Y9bobBkJ
--HG--
extra : rebase_source : 520b78dec4daca5050e0cc7fff4ec68fa36663c5
We force a repaint from ContentStateChangedInternal if visited links are
disabled, and that's observable. Let's cut it off as early as we can to avoid
timing attacks even when :visited is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D3304
Brian Birtles
Emilio Cobos Álvarez
Razvan Maries
garvitdelhi
Cosmin Sabou
Ryan Hunt
Margareta Eliza Balazs
Ehsan Akhgari
Bogdan Tara
Daniel Holbert
Sylvestre Ledru
Jonathan Watt
Tom Klein
Hiroyuki Ikezoe
Gerald Squelart
Ting-Yu Lin
Cameron McCormack
Ting-Yu Lin
Xidorn Quan
Narcis Beleuzu