Instead of hardcoding a color-to-compare, compare the contrast between
the text and the background color v.s. text and the alternative
background color, and use the color that has better contrast.
MozReview-Commit-ID: D90047Y0Xst
--HG--
extra : rebase_source : cc0bd290930dbb11f464aa434b7606bab268627a
Closing the temporary file was done in the FileBlockCache destructor, which is
called on the main thread.
Instead, we are now dispatching a new final task from Close, which will close
the temporary file and then shutdown the thread.
The thread and FD ownerships are transferred to that final task, so that no
more tasks may be unexpectly queued to that thread, and both members can
immediately be reused after Close() returns.
MozReview-Commit-ID: L9djYGhDFn4
--HG--
extra : rebase_source : bedad374454ec94966d10552b8aea26c8997fbb9
In a parent process, the temporary file was created and opened by calling
NS_OpenAnonymousTemporaryFile() from Init, which was called from the main
thread.
In addition to being called at least once when the first media file is fetched,
it may also be called if caches need to be emptied.
So it should help to move this operation on the FileBlockCache thread, if only
to remove potential background-hang reports from non-e10s configurations.
MozReview-Commit-ID: CjPsHEsL3Ch
--HG--
extra : rebase_source : beaa2793dea82d853669d87c9434139d88562da9
SetCacheFile, Init, Close, and MoveBlock all had NS_IsMainThread() assertions.
However they all use Monitor's to access member data, so they should be thread-
safe.
(Upcoming patches will actually start using some of these functions from non-
main-threads.)
MozReview-Commit-ID: E1auNEXuoF9
--HG--
extra : rebase_source : 41af7d16f8a9bde5492e864712981a208f3b47be
The main reason for these changes is to avoid initializing the bookmarks service too early,
plus a lot of micro-optimizations to reduce the code-bloat compared to the previous bogus
(but slick) async getter.
MozReview-Commit-ID: Fy4fshsDaIw
--HG--
extra : rebase_source : 3ad245e932e718ee5ca1fa8da4df8a0f8efd3f0b
<!-- Please describe your changes on the following line: -->
Most elements don't have classes or IDs.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix https://bugzilla.mozilla.org/show_bug.cgi?id=1365659
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they are just performance optimization
<!-- 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: 2fd7f4f393874d2a2a8285e18f0288d18554454f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6addae8f2078c73e9461327d4edfe22a4e1be623
- Avoid any potential for this going away from underneath the dispatch
to STS thread.
- Added notes in PeerConnectionImpl on the test-only nature of the
AddRIDExtension, AddRIDFilter, and GetMediaPipelineForTrack methods.
PeerConnectionImpl::GetMediaPipelineForTrack by returning a reference
to the RefPtr instead of a copy.
MozReview-Commit-ID: EwMr9ulKtm8
--HG--
extra : rebase_source : 55c8b14f63020feda57accd2b4b331de708866c4
Now that Chrome release is bundle-aware, let's reapply the patch to
properly emit port 0 for m-lines in sections with the bundle-only
attribute.
MozReview-Commit-ID: 8RftSXIzIpD
--HG--
extra : rebase_source : 6f9c4cb6b322aec7c00060827e1f5e7852f8acfc
The reason of this change is the same as for Part 2, except that this commit fixes
nsSVGPaintServerFrame::GetPaintServerPattern rather than PaintSVG.
Commit-ID: 691YrKZ0Lm9
MozReview-Commit-ID: KSnFhCndFUk
--HG--
extra : rebase_source : 3397613129fff6023833cdc3bd639f0d2b151652
extra : source : fa29f1920a88d88bcf0f5239462d32ee8955895c
The reason of this change is the same as for Part 2, except this commit fixes
nsSVGMaskFrame::GetMaskForMaskedFrame rather than PaintSVG.
MozReview-Commit-ID: DS0eG6eKDgs
--HG--
extra : rebase_source : 696bf495edc98a390f49ff0638165724521460b1
extra : source : 95f38c2c8b57134504e7fbe03d1637866e3e65ba
The DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
--HG--
extra : rebase_source : 66c9a9e391c2f9e142575f42fd47b37334ec5752
extra : source : 97a08873177c0f18edffdb1b5589c77843a50553
A struct used during painting to provide input flags to determine how
imagelib draw calls should behave, plus an output DrawResult to return
information about the result of any imagelib draw calls that may have
occurred.
MozReview-Commit-ID: 3jGEh5vEPF
--HG--
extra : rebase_source : 6a40d1bca79425dabf28538b5492cb090074223e
https://bugzilla.mozilla.org/show_bug.cgi?id=1365686
Let's get this in to see the impact on Talos.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9d887a23756c9b646394831a073a3a0cbfc07e15
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4267cac66cf2c564a24178bd4fb595780c352fb6
This allows `make check` to pass when run against these builds.
MozReview-Commit-ID: BVs6BPifbfW
--HG--
extra : rebase_source : ebad40260b160744e0d2f9dfc52a74b7e5e5ae0e
We are seeing occasional failed release assertions from calling
animation.startTime().get_TimeDuration() in SampleAnimationForEachNode on
Windows.
My theory is that in some circumstances (perhaps graphic-driver related?) when
creating a layer transaction we fail to call Layer::StartPendingAnimations and
end up sending pending animations to the compositor. Prior to bug 1334583 that
would have only triggered a debug assertion so it may have gone unnoticed if it
depends on the system configuration.
This patch makes us check that the startTime is set before we try to access it
in order to avoid triggering a release-time assertion. If the startTime is not
set we will use the hold time which should give us the correct behavior for
a still-pending animation. (Furthermore, the holdTime is set unconditionally
when we create animations so it should be correct -- but even if it were not
set explicitly, its initial zero value would still likely produce a reasonable
result until the start time was updated on a subsequent layer transaction. At
very least, it should not crash. Likewise, if it was set to an incorrect value.)
This patch also strengthens the debug assertion in SampleAnimationForEachNode to
check that not only is start time not-null, but that it is set to a TimeDuration
since MaybeTimeDuration also includes a third uninitialized "None" state.
<!-- Please describe your changes on the following line: -->
This PR implements the current draft Houdini Worklets specification (https://drafts.css-houdini.org/worklets/).
The implementation is intended to provide a responsive environment for worklet execution, and in particular to ensure that the primary worklet executor does not garbage collect, and does not block loading module code. The implementation does this by providing a thread pool, and performing GC and module loading in a backup thread, not in the primary thread.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#16206
- [x] There are tests for these changes
<!-- 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: ac99a48aeaa184d3acdb39d249636a140c4b7393
--HG--
rename : servo/components/script/dom/webidls/Function.webidl => servo/components/script/dom/webidls/VoidFunction.webidl
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : d4069e68d5b007ec258bf5821d6386a3ec63c490
Rebuild the one-off search buttons when the theme changes. See bug 1357800 for details. Summary: On Linux, switching between themes can cause a row of buttons to disappear.
MozReview-Commit-ID: 8lfsUO00jYP
--HG--
extra : rebase_source : 5bdef5513a8c8f8f02fd9383867b0ed57610b606