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
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
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
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
(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
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
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
It's good to save a copy constructor call.
Also, make nsBlockFrame::SplitFloat() return void because the only
caller (BlockReflowInput::FlowAndPlaceFloat()) doesn't check its return
value, and (more importantly) because it only ever returns NS_OK.
MozReview-Commit-ID: 9LmDCXd7xGS
We use nsFlexContainerFrame (our modern flexbox implementation) to emulate
-webkit-box, and we use a frame state bit to tell us whether to use
modern-flexbox properties vs. legacy properties. Up until this patch, we
neglected to check that state bit when determining whether to use the modern
"flex-basis" property for sizing. This patch makes us *not* use that property
(and just use the axis-appropriate width/height property instead) for legacy
-webkit-box containers.
MozReview-Commit-ID: 14bzOCPCtUY
* HasAnyStateBits is slightly more foolproof and readable -- in particular, you
can put the logical "!" directly alongside the expression, rather than
needing to separate it with a layer of logical-grouping-parens.
* The deindentation here isn't super-important, but it conforms better to our
coding style, and it'll make this code consistent with a new chunk that I'm
adding in the next patch (and that chunk will *have* to be deindented like
this, to avoid going over 80 characters).
MozReview-Commit-ID: FWfqrKjHedP
The failure mode in the attached crashtest is an inconsistency in the flattened
tree. Specifically, we null out mVideoControls in an nsVideoFrame, but defer
the UnbindFromTree call on that NAC element, which measn that its mParent still
points to the nsVideoFrame's mContent. Because all this stuff runs off of script
runners, and the anonymous content destroyer is not guaranteed to run before
other potential script runners, we end up running arbitrary script while the
tree mismatch exists. This script calls back into ProcessPendingRestyles, which
causes trouble.
We could build a separate deferral mechanism, but it's not clear that we actually
need to defer the unbind anymore. The deferred unbind was added in bug 489008,
which predated a lot of simplifications in layout/dom interaction.
MozReview-Commit-ID: 1JYAhiXKVJC
Another plumbing-only change, which is a precursor for the next patch.
ComputedValues are a Servo-only thing, so in order to use nsStyleSizes for both
Gecko and Servo, the ComputedValues sizes must be moved out.
MozReview-Commit-ID: BOnQSzzV0vC
This is a purely non-functional plumbing change. Instead of passing a
SizeOfState and an nsStyleSizes a bunch of places, we pass an nsWindowSizes,
which contains both of them.
This is a necessary precursor for the next patch.
MozReview-Commit-ID: Ek03wDM50rB
For the Obama wikipedia page, this covers about 85% of the unmeasured
ComputedValues structs. The about:memory output looks like this:
> +---2,443,648 B (02.41%) -- computed-values
> | +--1,088,272 B (01.07%) -- dom
> | +----945,744 B (00.93%) -- non-dom
> | +----409,632 B (00.40%) -- visited
I'm not sure why some CVs are still being missed.
MozReview-Commit-ID: 1bYWwSi4ihn
This change ensures that HTML frames with SVG filters applied are given the
correct overflow regions so that they will display and invalidate correctly.
The bug that this commit fixes does not manifest in many cases since
often elements happen to be reflowed more than once when a document loads.
When that happened the bug would be masked because the filtered frame would be
given a size during the first reflow, and that would then make the overflow
calculations in subsequent reflows work. It was only in cases where the
filtered frame was only reflowed once (such as when dynamically inserting a
filtered element into the DOM using script) that the lack of a valid frame
size during the overflow calculations would result in bad overflow regions
being calculated.
MozReview-Commit-ID: 79lR27KRSym
