When we compose style for a given nsCSSPropertyID in the case where
we have no specified values in target keyframe, we use this AnimationValue
for composition as if it's specified.
MozReview-Commit-ID: 2CTLIGgeLIO
--HG--
extra : rebase_source : 3be5bdaf3d226ff004bb0af0f832e5af88f15b6d
This base value will be used for additive, accumulative animations
and also SMIL.
MozReview-Commit-ID: LHV8ZnxSzjb
--HG--
extra : rebase_source : 507a8dd74961e7f439b90fd4c5f90a98706aa434
This fixes the failure of
layout/reftests/css-grid/grid-min-max-content-sizing-002.html with the
primary patch in bug 1308876 (which causes a child whose parent is dirty
to pick up the dirty bit from the parent only the first reflow of the
child if the parent reflows the child multiple times). A simplified
testcase for that failure is
https://bugzilla.mozilla.org/attachment.cgi?id=8849771 .
The failure was caused by an error in height calculation of the first
<x> in the test. The div that is the parent of that x has a definite
height (presumably due to rules in grid), and the x has a specified
height. The div gets three reflows: two measuring reflows (from
MinContentContribution and then from MaxContentContribution) and then a
final reflow from nsGridContainerFrame::ReflowInFlowChild. Prior to the
primary patch in this bug, the div was marked dirty on all three
reflows, but with it it is marked dirty only on the first. This means
that, without the block-resize flag, the div optimizes away the reflow
of its children, since ShouldReflowAllKids returns false because
IsBResize() is false, even though NS_FRAME_CONTAINS_RELATIVE_BSIZE is
correctly set.
In order to fix this, we need to make sure the BResize flag on the
reflow state in at least some cases (see the comments in the patch for
when, and for how the cases could be optimized in the future).
Note that:
* when the dirty bit is set on the grid container, the new behavior
(with the combination of the patches) is strictly more efficient than
the old, since we will sometimes do non-dirty reflows on the grid
items (with the b-resize flag)
* when the dirty bit is *not* set on the grid container, the new
behavior is less efficient than the old, since we will set the
b-resize flag when we did not do so before. However, this slowdown
fixes existing bugs such as the one in the reftest.
Given that I was able to construct a reftest that triggers the failure
without the changes from bug 1308876, I've moved this to a separate bug.
Without the patch, grid-measuring-reflow-resize-dynamic-001.html fails,
but grid-measuring-reflow-resize-static-001.html passes. With the patch
both tests pass. (And without the patch, doing a text zoom on the
dynamic test fixes the layout error.)
MozReview-Commit-ID: JQOdVTQIkU0
--HG--
extra : transplant_source : %8B%2ARO%3B%D0%7B%EC%C9_%B3%60Sp%F9T%14X%85%DC
In the new architecture of Quantum DOM, all timer callback need a
specified event target. So, we add the new document arg to Start
function to get the event target from it. And update all callers.
MozReview-Commit-ID: a482mukqGc
--HG--
extra : rebase_source : 36f9d47a4afd7c7113adf3f274656b694b8d0943
In the new architecture of Quantum DOM, all runnables need a name label.
So, we add the new string-label arg to Start function, and update all
callers.
MozReview-Commit-ID: G9LXFjtFcQv
--HG--
extra : rebase_source : a19b605013be56d01780c831d2a48ada8825b1c7
This patch makes nsRepeatService stop inheriting from nsITimerCallback.
We needed that inheritance for InitWithCallback, but we do not need it
for InitWithFuncCallback.
This patch also makes nsRepeatService singly-owned instead of being
refcounted, since we're left with only a single owning pointer.
MozReview-Commit-ID: Fl8beVC8kGH
--HG--
extra : rebase_source : 3b6223c8e4754a90d2fef460940fda4510310f95
There are scenarios where we have a TabParent in the UI process hooked up to
a PuppetWidget with a BasicLayerManager. Webextensions fall into this category.
In this scenario, the parent-side layer manager is not hooked up to
the compositor (that is, there is no entry in the CompositorBridge layer tree
state map for the layers id). However, the content-side still ends up creating
a ClientLayerManager or a WebRenderLayerManager, which expects the layers id to
be registered in the compositor. This results in brokenness (in the case of the
ClientLayerManager/PLayerTransaction) or crashes (in the case of WebRenderLayerManager/
PWebRenderBridge). Instead, this patch changes this scenario to have the content
process use a BasicLayerManager which seems safer.
MozReview-Commit-ID: 3f80aZrRrmD
--HG--
extra : rebase_source : 10ec78dd7daf1c1c889929f0d79e0b75675b4b05
Instead we can use the otherwise-unused function to check if initialization worked.
Technically, because of the way RenderFrame construction works, whether or not
initialization succeeds is exactly dependent on whether or not the frameloader is
non-null, so we could even just use that to check success. But this feels slightly
more readable/cleaner.
MozReview-Commit-ID: CGiIAA1h6V7
--HG--
extra : rebase_source : 2d4504f7d5fde3c394edca14fe01840c1738d197
There is already a GetLayersId function in RenderFrameParent.h that does the
exact same thing, and this private function is only used in one spot. Seems
unnecessary.
MozReview-Commit-ID: 6i7lwKQsSFM
--HG--
extra : rebase_source : 6cf688f6f4300bedffebfbb94d431deec0bff209
The FFI type conversion in AnimationValue::as_arc will check if the
parameter is nullptr or not. If it is, we will get a debug assertion, so
we shouldn't pass a nullptr into it.
MozReview-Commit-ID: KWko2ipJwbo
--HG--
extra : rebase_source : f3e284da008b6c3bb3c56eb26c485f825b1188a7
We will obsolete StyleAnimationValue in the future, and can treat
AnimationValue as a wrapper of RawServoAnimationValue to hide the FFIs
at that moment. For now, we still need both types, so it's better to make sure
they are mutually exclusive in AnimationValue. Therefore, let's add some
assertions.
Besides, I think those FFIs might do many things and it seems those methods
are not critical, so let's move them into the cpp file, so we can remove
some dependencies to avoid re-compiling so many files if someone needs
revise ServoBindings.h.
MozReview-Commit-ID: FJ1uTvEQ7NT
--HG--
extra : rebase_source : 8ef99c659f2721c8425364051db19b66536bccc6
The recommended Marionette preferences for use in automation are not so
useful when testing the browser itself. Many of the tests for Firefox
have highly specific requirements, and setting the recommended Marionette
preferences could for these mean a deterioration of test coverage.
The majority of test harnesses utilising Marionette use it to install
unsigned add-ons at runtime, and these preferences are not relevant in
this context.
To avoid an unfortunate and unintended regression in test coverage,
we skip using the recommended Marionette preferences when we test the
browser itself.
MozReview-Commit-ID: 4DeHZfQEX7d
--HG--
extra : rebase_source : bf31d336df7c4c28c04454338a912632087aa3ff
