Currently nsIThreadManager::spinEventLoopUntil doesn't monitor the shutting
down. Firefox shutting down can be blocked by a 'broken' use of
nsIThreadManager::spinEventLoopUntil.
nsIThreadManager::spinEventLoopUntilOrShutdown should be used instead.
Originally, buildbot would try to directly execute `RUSTFLAGS=` as a binary
since it was the first token in the command string, which won't work.
Fix this by using the `env` command to set the environment variables,
as there is currently no support for setting per-step environment variables
in the `buildbot_steps.yml` file.
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes should fix#19821 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they change the CI configuration
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 025e5d773313e16ffe73ae63efc068b79b82d531
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f1acdfbff9c0c0bf16dcf5ae029222b525e5169f
Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
--HG--
extra : rebase_source : 286b3d5d29208496bfe8405819b44b5f52f6671c
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
--HG--
extra : rebase_source : 28c8e2a50d29c5344e2c5ca3c43af41f4692fa0f
Now we sort pending events only when dispatching the events, i.e.
only inside DispatchEvent().
MozReview-Commit-ID: BZbuF8gD39b
--HG--
extra : rebase_source : 2a90697356d980b1fd1329d34936eaef1179d12f
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
--HG--
extra : rebase_source : 405c8232e93c54a073c722a4332873af02daa870
In a subsequent patch in this patch series, we want to make nsPresContext
have an AnimationEventDispatcher as RefPtr<>.
Instead, if we were trying to make nsPresContext have the
AnimationEventDispatcher as data object (not RefPtr<>) just like we did in
CommonAnimationManager, we will fall into header inclusion hell since Element.h
includes nsPresContext.h and AnimationEventDispatcher.h ends up including
Element.h. Even if we could solve the inclusion hell, we will suffer from Rust
bindgen issues for some reasons.
MozReview-Commit-ID: B0nX2JzIRJD
--HG--
extra : rebase_source : 4eb998876b2fc39de8d09cac09c19e1a51cd382e
Now single AnimationEventDispatcher can handle both CSS animation/transition
events simultaneously. To do this we had to change AnimationEventInfo and
TransitionEventInfo into a single struct, the struct is also named
AnimationEventInfo.
It results we can sort both CSS animation/transition events altogether. Thus
we make sure CSS animation/transition events are sorted by scheduled event time
prior to their composite order (i.e. transitions is prior to animations).
At this moment, we don't sort both events altogether since nsAnimationManager
and nsTransitionManager has an AnimationEventDispatcher respectively. In the
next patch we move AnimationEventDispatcher into nsPresContext, i.e. each
document has an AnimationEventDispatcher without the distinction between
CSS animations and transitions.
Note that, after this patch, we copy all members in InternalTransitionEvent and
InternalAnimationEvent in the copy-constructor of AnimationEventInfo, this
will be fixed once WidgetEvent has move-constructor and move-assignment
(bug 1433008).
MozReview-Commit-ID: 5JAh6N7C6ee
--HG--
extra : rebase_source : 50da76f51cf65cdd1245d93d8b48aaf0ae0ec94b
We plan to use this class to dispatch web animation API events as well
(bug 1354501).
MozReview-Commit-ID: 7DMmc0aJzJ5
--HG--
extra : rebase_source : 445428771238ad31697cede8afbab35c1144a422
The comment is no longer correct since bug 1180125.
MozReview-Commit-ID: A4NWgmwAOFt
--HG--
extra : rebase_source : 57471f99bcbef86bf211692eee8cf06513f4b60a
It's not need to be a template function since the function is independent from
AnimationType.
MozReview-Commit-ID: 13WkRIfaQbZ
--HG--
extra : rebase_source : 5df3eb22dc2785b43718f388a9a32915a18c8be2
We just need information whether there is still an observer or not in most
cases. The only case we need to know the count is in an assertion in the
dtor of nsRefreshDriver. In the dtor we are checking there remains no
observers other than early runners.
Note that the order in HasObserver() was adjusted to reflect that we check
boolean flag first (mViewManagerFlushIsPending) and subsequently check observer
which is likey happen to. mFrameRequestCallbackDocs should have checked prior
to mResizeEventFlushObservers though.
MozReview-Commit-ID: E1qplusqw1Y
--HG--
extra : rebase_source : ebd9e6eb08952df954c55860638233c9a8729856
r? emilio
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19886
- [x] These changes do not require tests because it should not break anything
Source-Repo: https://github.com/servo/servo
Source-Revision: 64c514ac3a54254720440d869c1c739f7b2a6802
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 11acd8b191d15e680de77e244c9127ad8f95c100
Migrate RUST_BACKTRACE out of saltfs.
SCCACHE_IDLE_TIMEOUT has already been migrated.
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes help with servo/saltfs#770 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they change the CI configuration
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 1cb824d48e832b2e11b5e7341b188ad579b43111
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 1cc4d753a0a36683d0665a6adb7fd68d1fa5f65a
As far as I know, sccache is working properly
on the non-cross-compiling Linux builders.
For safety, only enable it for the builders that run on PRs,
to avoid breaking our nightly generation and scheduled test runs.
This will also allow testing new versions of sccache more easily.
This implements my suggestion from https://github.com/servo/servo/pull/19858#issuecomment-360514782, and should also let us
handle testing a new sccache: https://github.com/rust-lang/rust/issues/42867#issuecomment-358692077 (our current version of sccache [seems to be 2018-01-09](f50214b8fa/servo-build-dependencies/ci-map.jinja (L5))).
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they change the CI configuration
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 78ffce1cbe5fcce4d057b69c3cbf0cd2bc2b449c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 04b98e4452ebe655c59d54f42827b6f3c29b0cd9
This enables us to implement Element::has_css_layout_box() in a more
direct way, and also enables us to remove some of the existing more
specific queries.
Fixes#19811.
r? @emilio
Source-Repo: https://github.com/servo/servo
Source-Revision: 2a46067587d63aec176621ab3b6112ef5200a248
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 715f36d9bedb88b8bba29eff16913cb31a426305
The Web Authentication CollectedClientData is missing the type field, which
is just a simple string. (The editor's draft also removes hashAlgorithm, but
let's not get ahead of ourselves...)
Add in that simple string. This was found at interop testing.
MozReview-Commit-ID: DlawLyHTYhB
--HG--
extra : rebase_source : 6cdd8e14161dc4aea5bfd1baf60c7384219ba951
Firefox generally supports the same range of LLVM versions as Mesa.
Instead of regularly updating it just pull Mesa drivers which will
be required by WebRender, anyway.
MozReview-Commit-ID: DiK4TD9tWe0
--HG--
extra : rebase_source : 5dd9c8c46ae79deee8f2fd887b27fddbc30fc22d