This part is not necessary for fixing the reftests. But it would be better to just
return true if we don't want to render this item.
MozReview-Commit-ID: 6w6MCUAFPj6
--HG--
extra : rebase_source : 858ed1e406cd537eb5754f3d8f8eec1497034e70
The specialized cascade flow in `stylist::compute_style_with_inputs` (used with
reparenting) currently computes all properties for visited styles, but we only
need visited-dependent properties.
This adds the cascade flag to reduce the work to visited-dependent properties
only, like we do for the regular cascade flow.
https://bugzilla.mozilla.org/show_bug.cgi?id=1407813
Source-Repo: https://github.com/servo/servo
Source-Revision: 82a013ae073e1e546d80866710ca395bb71cab7c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 43509a41dbbfb4b7d32d6dfbe8120e66b1af74da
Removed non-eager DDLogValue() functions, too confusing for not much value;
users should use macros first anyway.
Changed `EagerLogValue(..., const char (&aLiteral)[N])` to take `const char*`,
it's cleaner and simpler.
MozReview-Commit-ID: J7xcoPkp6Nf
--HG--
extra : rebase_source : 41040c98b89c3035c823a4a9775e727038c07590
This patch changes ClientID.jsm to only check for the pref validity if
the cached client id pref was set.
MozReview-Commit-ID: KI3YHaMozl6
--HG--
extra : rebase_source : 14d7c2408a16d21911c10112465c2afe590c85fb
Try looks good. Let's turn it on for more tests on Nightly.
MozReview-Commit-ID: 21mQfRmOYag
--HG--
extra : rebase_source : 8f51bd517816deba68dad511a9f859ab1df25baf
extra : intermediate-source : 5150eb8b0826be6578b2d8c68d6d864cc9f55f25
extra : source : 63542cbae67928b936f0472b8dca1f7035759115
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : ecce8ac75587470c15268ab729b068f049702a8a
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 9e455022ba9360fb549222e9ad1238a3ae9d88ad
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : 0d20f1b8648acaf2ed8e75b2631e905629c2abaf
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
These help slightly with https://bugzilla.mozilla.org/show_bug.cgi?id=1405411.
Source-Repo: https://github.com/servo/servo
Source-Revision: 99e15f0f03fceb97f2dd54e049fc133a7001c157
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : dc9f5bbe50ec95ccb8dcc41842ce6c93e1afc50f
Servo half of https://bugzilla.mozilla.org/show_bug.cgi?id=1407246, reviewed there by Emilio.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9f8514d2b94713b6dc3bb918f8ffa9fac66021a3
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b1173244f5ba3e9c386721d4eb07085db144342c
When SplitNode returns nullptr, GetAsText causes crash. So we should check
error before casting by GetAsText.
MozReview-Commit-ID: 8E1OPSRZ2x5
--HG--
extra : rebase_source : 48a067bd080e7a68e9d469c07d3b744508dae91f
As explained in the extended comment in this patch, for Servo we want to post
restyles when creating new animations so that we run a second animation
restyle and incorporate the result of new animations into style immediately.
(Gecko does everything in the one restyle, and although this causes other bugs
related to triggering transitions, at least it means it does not require
restyles to be posted here).
It turns out that we normally end up posting a restyle anyway in
CSSAnimation::SetAnimationIndex. Bug 1332958 was supposed to drop that but it
never landed.
However, CSSAnimation::SetAnimationIndex only posts a restyle when there is
a change to the animation index. It turns out that, by chance, there normally
*is* a change to a CSSAnimation's animation index when it is created. Initially
it takes its animation index from Animation::sNextAnimationIndex which is
incremented each time it is assigned to an animation.
If the first Animation we create for a given content process is a CSSAnimation
then sNextAnimationIndex will be zero and so we will initially assign an
animation index of zero. If that CSS animation is also the first in the list
of animations in animation-name, when we call SetAnimationIndex we will pass
zero as the index to use, and when we go to update the animation index we will
detect that there is no change, and will NOT post an animation restyle.
As a result the target element's style will NOT reflect the animated style.
To fix this we need to ensure that *new* CSS animations trigger a restyle.
For *changes* to animations, the corresponding calls to SetKeyframes and
SetSpecifiedTiming post restyles so the behavior should be correct in those
cases.
For *removed* animations I observed that in at least some cases we successfully
post a restyle. However, this appeared to be as much by chance as anything so
this patch also posts a restyle for removed animations. (Note that the
EffectCompositor will ignore redundant restyle requests so this is ok.)
This patch deliberately does not expose Animation::PostUpdate and call that
because the code introduced here is intended to be temporary. Long-term we
should remove the Gecko style backend and allow the calls to PlayFromStyle,
PauseFromStyle, CancelFromStyle etc. to post restyles just like calls to Play,
Pause, and Cancel do. At that point this code can also be removed.
MozReview-Commit-ID: 4c3vJdLBqeY
--HG--
extra : rebase_source : 684cb483562709161b2d5635e173e55319509a70
The != tests actually pass, but this is hard to express in the failures.list
pattern matching, so we just mark them all as random.
MozReview-Commit-ID: 2qr8a1isSEV
--HG--
extra : rebase_source : 14d2756ea044065579e1b3937d8417a3ef004317
