The last places that call this function have been removed in
https://hg.mozilla.org/mozilla-central/rev/0f7e0529ee3f,
and never been used since then.
MozReview-Commit-ID: FQtnwRHQ8cH
--HG--
extra : rebase_source : 3c40d0077c4b38771deed7055fbc5e22be8a071f
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
Before this patch, we had been checking each scrollable ancestor is scrolled
out of its scrollable ancestor. So if the target animating frame is at the
bottom of its scrollable parent and if half of the scrollable parent is
scrolled out of its ancestor, the animating frame was considered as 'in-view'.
MozReview-Commit-ID: BDueuF3cT4I
--HG--
extra : rebase_source : de1dead6e67a44691887c8364be23734c3b1adef
Before enable stylo, an image request is always been resolved before the
creation time of that request object[1].
As a result, in AddAndRemoveImageAssociations, we always associate the request
objects of style images with the given frame(since they are resolved).
After enable stylo, an image request is resolved after that object been created[2].
We may hit the assertion reported in this bug by the following senario:
1. AddAndRemoveImageAssociations is called. The image request is not resolved
yet, so we do not associate that frame with that image request.
2. That image request is been resolved via nsStyleXXXX::FinishStyle.
3. Style changed. AddAndRemoveImageAssociations is called again. We try to
dis-associate the frame with image request and hit this assertion since
this frame is not associate with any image request at step #1.
[1]
We use this constructor if the backend is gecko
https://hg.mozilla.org/mozilla-central/file/5ed2f3c94155/layout/style/nsStyleStruct.cpp#l2131
[2]
We use this constructor if the backend is stylo
https://hg.mozilla.org/mozilla-central/file/5ed2f3c94155/layout/style/nsStyleStruct.cpp#l2147
MozReview-Commit-ID: 22trSbdogUH
--HG--
extra : source : 835239788497126e3be33a0dbbb0543e94fc9f18
extra : amend_source : b3e94ac2c639d89bac4745350f88d3383e6faf76
We create empty rectangle (zero-height or zero-width) frame for element which
has no content inside it, e.g. '<p></p>'. And nsRect.Intersects returns false
if either of the rectangles are empty, so if we check
!transformedRect.Intersects(scrollableRect) and transformedRect is empty, we
will end up returning true from IsFrameScrolledOutOfView even though the point
represented by the empty transformedRect might be inside the
scrollableRect.
The reftest causes timeout without this fix since the animation never updates
after the initial paint.
MozReview-Commit-ID: FymFJfjxyGc
--HG--
extra : rebase_source : 6ebcd354be300b779e84f013fa4db7d13e36c551
We need this change to generate nsDisplayOpacity for the continuation or
ib-split-sibling frames other than the first continuation so the opacity
animation on the continuation frames runs on the compositor.
When we generate an nsDisplayOpacity, the animation runs on the compositor,
but when we don't, the animation never updates since the animation is throttled
on the main thread.
MozReview-Commit-ID: DESftTLt0wq
--HG--
extra : rebase_source : bde757fe5ae7efb9ed739d542ee92665e66da261
If there is no EffectSet for the frame, it means no animation runs on the
element for the frame.
MozReview-Commit-ID: Ev9Hf3jquvU
--HG--
extra : rebase_source : 4a87cbfdb6f069654bb2fe829824d45a7956f0f6
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
These became unused as a result of the removal of nsRegressionTester and
the removal of the printing debug file mechanism, earlier in this patch
sequence.
MozReview-Commit-ID: 9Tftf2AjpPb
When we generate the glyph mask for a transformed frame in
GenerateAndPushTextMask, the transform vector had been applied into aContext[1],
so we should find a way to prevent applying the vector again when painting the
glyph mask.
In bug 1299715, I tried to prevent double apply at [2], it caused two problems:
1. We only skip generating nsDisplayTransform, but we may still create a
nsDisplayPerspactive bellow. Since the parent of a nsDisplayPerspective must be
a nsDisplayTransform, which have been ignored, so we hit this assertion.
2. We skip all transform for all frames while painting the glyph mask, which is
not correct. We should only skip double applying transform vector of the root
frame.
This patch fixes both of these issues:
a. We will still create a nsDisplayTransform for the root frame if need. But
the transform matrix we apply into the target context will be an identity
matrix, so we fix#1 above.
b. In #a, we change the transform matrix to an identity matrix only for the root
frame of the glyph mask, so we fix#2.
[1]
https://hg.mozilla.org/mozilla-central/file/59e5ec5729db/layout/painting/nsDisplayList.cpp#l752
[2]
https://hg.mozilla.org/mozilla-central/file/ce2c129f0a87/layout/generic/nsFrame.cpp#l2806
MozReview-Commit-ID: 973lkQQxLB6
--HG--
extra : rebase_source : aef80444e94d3af7eca776c981f8faded03bc985
nsFrame::SchedulePaint() invokes InvalidateRenderingObservers, and
InvalidateRenderingObservers ends up posting change hints during we are
processing sequential tasks for animations, but we don't allow posting any
change hints while we are in the middle of restyling process.
Though the change hints posted by InvalidateRenderingObservers are not harmful
in this case since the change hints will be processed in a second post
traversal without problems. That's said, InvalidateRenderingObservers stuff
should be processed in display list based invalidation anyway (bug 1284053).
MozReview-Commit-ID: GKVRZ98lvEN
nsReflowStatus::IsEmpty() assertions are added after DISPLAY_REFLOW in the
beginning of the Reflow().
A few Reflow() implementations have Reset() calls at the end which are left
in place by this patch (with an explanatory comment added to each). These
ending Reset()s are only needed for cases where a non-splittable frame
passes its own nsReflowStatus to a child's reflow method. Just in case the
child leaves a "not fully complete" value in the nsReflowStatus, the
non-splittable parent frame must clear out the nsReflowStatus before
returning, so that its own parent doesn't then try to split it.
MozReview-Commit-ID: 6Jj3jfMAqj4
--HG--
extra : rebase_source : e1fe6a775ad97e16a6d7cc224634ff962ccb0fbf
