<!-- Please describe your changes on the following line: -->
```
warning: unused import: `Auto`
--> /Users/tigercosmos/servo/tests/unit/style/properties/serialization.rs:9:40
|
9 | use style::values::{CustomIdent, RGBA, Auto};
| ^^^^
|
= note: #[warn(unused_imports)] on by default
```
---
<!-- 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
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- 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: f17564926300e759d38f4ebdf0eefd064357af3f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9eaaf02d839c57eb3aaf95a98dcb12394b3602d0
Animation.finish() in a micro task for Animation.ready leads to a restyle and
a redundant restyle due to bug 1415457. The redundant restyle has been observed
in a single frame without the conformant Promise handling. But once we have the
conformant Promise handling we can tell it in a later frame.
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1415457#c1 to know what's
going on there)
MozReview-Commit-ID: FoojunfYZ6k
--HG--
extra : rebase_source : 2820dce4513329fb648ef387d58cac469f680a6d
The expected restyle count depends both on animation state and micro task
handling.
If we have the conformant Promise handling and if the animation begins at the
current time, we will observe 1 less restyles than observed frames since we
skip the first restyle in the initial frame. This represents correctly what
we do and what we *should* do.
If we don't have the conformant Promise handling and if the animation doesn't
begin at the current time, we will observe 1 more restyles than obsered frames
since the Promise in observeStyling (precisely the Promise is inside the
callback for requestAnimationFrame) is fulfilled once after a restyling process
followed by the requestAnimationFrame.
MozReview-Commit-ID: FLhSRx4y1V7
--HG--
extra : rebase_source : 59e2bb2439f69bc1415a441c0b84a81463d8229f
The test case checks document timeline's currentTime to make sure that we are
in the first frame which happened after 200ms since the animation started. It
is unfortunate for us from the point of view of restyling that the first frame
includes the restyling process in the frame without the conformant Promise
handling, doesn't include the process with the Promise handling. So we need
to tweak there depends on the Promise handling.
I did intentionally add the forked version of the function with the same name
since branching depending on the conformant flag inside the original function
will be hard to understand and also we can easily remove the original version
once we have the conformant Promise handling.
FWIW, here is the diff between them:
@@ -365,6 +365,9 @@ waitForAllPaints(() => {
await SpecialPowers.pushPrefEnv({ set: [["ui.showHideScrollbars", 1]] });
+ // Make sure we start from the state right after requestAnimationFrame.
+ await waitForFrame();
+
var parentElement = addDiv(null,
{ style: 'overflow-y: scroll; height: 20px;' });
var div = addDiv(null,
@@ -379,13 +382,17 @@ waitForAllPaints(() => {
var markers;
var now;
while (true) {
- markers = await observeStyling(1);
- // Check restyle markers until 200ms is elapsed.
now = document.timeline.currentTime;
if ((now - timeAtStart) >= 200) {
+ // If the current time has elapsed over 200ms since the animation was
+ // created, it means that the animation should have already
+ // unthrottled in this tick, let's see what observes in this tick's
+ // restyling process.
+ markers = await observeStyling(1);
break;
}
+ markers = await observeStyling(1);
is(markers.length, 0,
'Transform animation running on the element which is scrolled out ' +
'should be throttled until 200ms is elapsed');
MozReview-Commit-ID: 3WfY6aVnsXk
--HG--
extra : rebase_source : ddf51217f03fc1bfe421c344a7a7811dc591a9af
This allows to re-use the SharedThreadPool across calls, preventing the need to create a new thread on each call.
MozReview-Commit-ID: CbP6OTYKhHL
--HG--
extra : rebase_source : 969f2c74f00614d6265fe0e25abfb36c9648d564
Additionally, remove no longer relevant MediaThreadType documentation as all MediaDataDecoder API are now asynchronous and we no longer have cancellable taskqueues.
MozReview-Commit-ID: 1F0YUhNniAn
--HG--
extra : rebase_source : 7b93ef24f91ccc21537e78bbb8a2d82bafacd29e
Most arguments of the constructor of CompositionTransaction are now stored by
EditorBase::mComposition. So, making it take TextComposition reduces the
number of its arguments.
Note that this patch doesn't make it retrieve TextComposition with
EditorBase::GetComposition() for guaranteeing that the editor has non-nullptr
mComposition.
MozReview-Commit-ID: 3O5wL52UBUy
--HG--
extra : rebase_source : 7f48465ef3f2f040e8c526fb7837060ecb6c9147
EditorBase stores a text node, offset in it and length in it of composition
string directly. However, this wastes memory space if user never uses IME
or user only sometimes uses IME. Additionally, storing all data in
TextComposition is better than current design when other classes like
CompositionTransaction wants some information of both EditorBase and
TextComposition.
This patch moves those 3 members from EditorBase to TextComposition.
MozReview-Commit-ID: 4N7wmGGfxmt
--HG--
extra : rebase_source : bd7cb37fe9631b959ec21da40c20751fec269dca
This has been reviewed in [Gecko bug 1425548](https://bugzilla.mozilla.org/show_bug.cgi?id=1425548).
Source-Repo: https://github.com/servo/servo
Source-Revision: f7440bf1a68cd0beaf12621c9c460c6f6ddc57e3
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : be54a712cafe4eb7fb42bc073bd687f6fd0220cb
There's no need for a custom class to perform this task.
MozReview-Commit-ID: JxpDQVM97fl
--HG--
extra : rebase_source : 8387efa0ed3add9e4a42daed98e97372d9cabee5
We keep the synchronous version that will be used in bug 1424653
MozReview-Commit-ID: JTGaRYm20ca
--HG--
extra : rebase_source : aa694b7ac4f03322edbdefd64cefd198c0909cec
The operations is done in two ways:
1- Process all the MediaStreamListener at once, which returns a promise that will be resolved once the operation is completed.
2- As the Cubeb audio callback must be resolved immediately, the MSG will wait for all the promises to be resolved until it continues the operation of feeding the callback the necessary data.
This will allow to parallelize the stream's tracks' audio decoding.
MozReview-Commit-ID: EeoDvxnJyWV
--HG--
extra : rebase_source : 3d09af5aa3c80c4892a4d9af80842541d8fc33bb
Takes either a MozPromise or an AllPromiseType and will execute the resolve/reject functions synchronously once the promise has resolved/rejected.
MozReview-Commit-ID: EyfMTPtA1Lu
--HG--
extra : rebase_source : 780ab41307158d7887cd76782e43693079f78c91
https://m.aliexpress.com is a good target to test. But it sometimes show mixed content, sometimes not.
I also chnage the check when adding a PWA shortcut. Only fail fast in nightly and local build.
MozReview-Commit-ID: 4sLoNERIYuW
--HG--
extra : rebase_source : 18663f8aafa5029afa1dd443cb9029ad3dd44abd
CC https://github.com/servo/webrender/pull/2215
Also, `[replace]` prevented using `[patch]` for other crates. (Cargo forbids using both.)
Source-Repo: https://github.com/servo/servo
Source-Revision: 3a37d8093108b66fb3edc212c97551738450c402
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 446a416f4a7c2e85487eb7cc00731adf09d7982a
There were two steps happening inside ExtractPendingInput:
1- Retrieve the data from the StreamTracks
2- Process any pending pending states change
We split it so that the retrieval from the StreamTrack can be promisified in an upcoming change
MozReview-Commit-ID: 53O4fXWMDGL
--HG--
extra : rebase_source : da082fa8db3a9029dc05d845cb9f58514f5ffcff
Bug 1382444 added this line to testing/profiles/prefs_general.js:
> user_pref("places.database.lastMaintenance", 7258114800);
(7258114800 seconds after 1970 is the start of the year 2200.)
libpref stores integers prefs as int32_t and the current parser doesn't detect
overflow. So this overflows to -1331819792. (I detected this with the new prefs
parser from bug 1423840, which does detect integer overflow.) As a result the
condition testing this pref in
toolkit/components/places/PlacesCategoriesStarter.js ends up always succeeding
in tests, which is the exact opposite of what was intended.
This patch changes it to 2147483647 (the year 2038), the maximum int32_t value.
MozReview-Commit-ID: LJQmMqQ9hFL
--HG--
extra : rebase_source : 84339c8e721abd47cb3cc85c3923a04417b1bbee
Aki Sasaki
Alex Chronopoulos
Martin Stransky
Sean Lee
Alexandre Poirot
Cosmin Sabou
Noemi Erli
ffxbld
tigercosmos
Jan de Mooij
Coroiu Cristina
Zibi Braniecki
Hiroyuki Ikezoe
Csoregi Natalia
Jean-Yves Avenard
Masayuki Nakano
Brian Birtles
Miko Mynttinen
Nevin Chen
Simon Sapin
Nicholas Nethercote