I've decided to fix this in a very explicit way. The only "magic" part that's
left is how we decide that the AGR of the perspective item is outside the
scrolled frame (and I'm not sure myself how that works).
I didn't want to change what scroll clips we set on what items, because the
scroll clip really belongs on the perspective item, because that's the item
that needs to be clipped, and it should also be the item that should be
scrolled if it weren't for the fact that APZ wouldn't know that it should
apply the perspective transform before the APZ transform.
MozReview-Commit-ID: BBw8VPohQI4
Always use an ancestor scroll clip of all direct children, or the original
scroll clip if the children don't share the same scroll clip tree.
Unfortunately this requires another pass over the stacking context display list.
Also, fix clips, scroll clips and creation order of blend items:
If a clipped mix-blend-mode item contains absolute / fixed positioned items,
those items should not be clipped, same for blend container items.
When a transform item contains blend modes, create the blend container inside
the transform.
Don't do tree comparisons on scroll clips from different scroll clip trees.
If the inner scroll clip is nullptr, because it was cleared, it will look like
it's the ancestor of the outer non-nullptr scroll clip.
These changes don't look very related, but it was very hard to get tests passing
with only some of the changes and not the others, and after having spent two
weeks on this patch I'm not thrilled about going back and checking exactly which
change was necessary to fix which test failure.
MozReview-Commit-ID: IKGciUBrdNa
This makes sure that for example the bounds of an opacity item are not empty if
the opacity item contains a scroll frame whose contents are currently scrolled
offscreen but still inside that scroll frame's display port.
On its own, this changeset causes test failures due to missed optimizations
because the bounds of many opacity items are now too large. That's because of
the way we're setting scroll clips on opacity items at the moment: Even if the
opacity is inside a scroll frame, we're currently only setting that scroll
frame's scroll clip on the opacity item's contents, not on the opacity item
itself, because the opacity item might also contain other items that are not
scrolled by this scroll frame.
The next patch in this bug will make us only do that when necessary.
MozReview-Commit-ID: 9TtcJ7eQE7U
Add helper function nsIFrame::In3DContextAndBackfaceIsHidden() which
checks both if a frame is backface-hidden and whether it is within a
3D-transform context.
In FrameLayerBuilder, check this function rather than BackfaceIsHidden()
to determine whether a frame needs a backface-hidden layer. This will
avoid creating unnecessary extra layers for non-3d-transformed items
which for some reason have backface-hidden set.
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.
Which is to return an empty scroll clip (instead of whatever scroll clip was accumulated in the for loop).
This patch is actually even slightly better than what we did before in that we can stop when we hit the root AGR (which is also the root reference frame) instead of the root of the frame tree. These would be different when painting a popup frame, or when not painting to the window.
