What goes on here is that there's a couple of unfortunate style change
sequences which end up making us not do the EffectsInfo dance correctly.
Twitter uses (maybe didn't use to, which would explain the regression) a
visibility: hidden, out-of-flow iframe for a bit (which we correctly
throttle). But then they switch to an in-flow, visible, zero-height
iframe. That we should _not_ throttle. However, we end up not getting to
the display list code at all, because nsBlockFrame decides that we don't
need to descend into an empty line[1].
It seems less error prone to re-use the IntersectionObserver timing and
computation to determine whether the iframe is visible. That completely
matches in-process iframes, too.
Removing the empty frame border and putting them on an empty line in
dom/base/test/test_bug1639328.html is enough to reproduce the issue
without this patch.
[1]: https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/layout/generic/nsBlockFrame.cpp#7569-7579
Differential Revision: https://phabricator.services.mozilla.com/D207479
What goes on here is that there's a couple of unfortunate style change
sequences which end up making us not do the EffectsInfo dance correctly.
Twitter uses (maybe didn't use to, which would explain the regression) a
visibility: hidden, out-of-flow iframe for a bit (which we correctly
throttle). But then they switch to an in-flow, visible, zero-height
iframe. That we should _not_ throttle. However, we end up not getting to
the display list code at all, because nsBlockFrame decides that we don't
need to descend into an empty line[1].
It seems less error prone to re-use the IntersectionObserver timing and
computation to determine whether the iframe is visible. That completely
matches in-process iframes, too.
Removing the empty frame border and putting them on an empty line in
dom/base/test/test_bug1639328.html is enough to reproduce the issue
without this patch.
[1]: https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/layout/generic/nsBlockFrame.cpp#7569-7579
Differential Revision: https://phabricator.services.mozilla.com/D207479
We no longer need the concept of "local" transforms after bug 878346.
Local transforms that we'd need in the future could be represented via
attribute mapping.
We still need the viewbox transform shenanigans which applies to
children only, tho.
Differential Revision: https://phabricator.services.mozilla.com/D220290
The tricky bit is rotate() which in SVG means something different if
there's an origin (you translate-then-untranslate it).
But this seems to work off-hand, and fix the reminder of bug 1906261.
Differential Revision: https://phabricator.services.mozilla.com/D215788
Ensure that when we construct a wrapping surface for a transform
due to a complex clip, we mark it as wrapping a backdrop-filter
when that is required.
Differential Revision: https://phabricator.services.mozilla.com/D217922
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
To take advantage of the new cairo capability, extend the link APIs to support
passing both a local destination name and a URI from the display list to the
rendering backend.
With this change, links to parts of the document that aren't included in the
print-to-pdf output will point back to the online resource, instead of just being
dead links.
(Note that this won't work the same on macOS at present, as we don't use
the cairo pdf backend there.)
Differential Revision: https://phabricator.services.mozilla.com/D211995
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
This is to avoid confusion with `IsScrollContainerFrame()` introduced in Part 3.
A note to performance concern:
We've used `IsScrollContainerOrSubclass()` in bug 1873414 to avoid expensive
`nsIScrollableFrame* sf = do_QueryFrame()`. Per [1], casting from `nsIFrame*` to
`nsIScrollableFrame*` has no fast path.
Ideally, `ScrollContainerFrame* sf = do_QueryFrame()` should be fast, and we can
use it to implement `IsScrollContainerOrSubclass()` like
`IsImageFrameOrSubclass()`. However, in this patch, I intend to keep the
performance metrics unchanged.
Remove `GetAsScrollContainer()` since it's only used in `MOZ_ASSERT`, and I'm
planning to remove `nsIScrollableFrame` in bug 1896516.
[1] https://searchfox.org/mozilla-central/rev/dd6e430c1bc2db90d9b3b1dd7e5215b4edc4d51a/layout/generic/nsQueryFrame.h#117-121
Differential Revision: https://phabricator.services.mozilla.com/D210395
When we call nsCanvasFrame::BuildDisplayList from nsHTMLScrollFrame::BuildDisplayList there is already a compositor hit test item in it, created here https://searchfox.org/mozilla-central/rev/ff08e36e1f368bd193b54f569dbd79105b50f9a0/layout/generic/nsGfxScrollFrame.cpp#4146
If we create a blend container item in nsCanvasFrame::BuildDisplayList it puts everything that might already exist in the display list inside the blend container item. It should only do this for the background items that we just created as this is for background blend mode, we are only blending within the background of this frame.
In the fuzz testcase we then have a partial display list build that visits the root scroll frame (because a scroll bar is dirty), so it builds the compositor hit test item for the canvas frame (the child of the scroll frame), but canvas frame is not modified, so we don't descend into it, and we don't call nsCanvasFrame::BuildDisplayList, so the compositor hit test item does not get wrapped in the blend container, and thus it has moved in the display list without being marked modified.
Differential Revision: https://phabricator.services.mozilla.com/D209511
This uses the support added in the previous patch to set an animation property
on a StickyFrame spatial node directly.
Depends on D208237
Differential Revision: https://phabricator.services.mozilla.com/D208238
Botond Ballo
Emilio Cobos Álvarez
Stanca Serban
Zach Hoffman
tannal
Jonathan Kew
Glenn Watson
Ashley Hale
aiunusov
Cristian Tuns
Iulian Moraru
Norisz Fay
Gregory Pappas
Otto Länd
Ting-Yu Lin
Sebastian Hengst
Olli Pettay
Timothy Nikkel
Narcis Beleuzu
Dan Robertson
pstanciu