We don't use the public UpdateCascadeResults method, so remove it.
MozReview-Commit-ID: A2lWZaHWHTZ
--HG--
extra : rebase_source : 35a1d77fdeba5a1db74d15f523dba78801b0b48e
We need this flag to avoid assertion in PostRestyleForAnimation(), which
may be called from MaybeUpdateCascadeResults() in pre-traversal.
MozReview-Commit-ID: 46AfoIUb9o3
--HG--
extra : rebase_source : 3290d9954be43ffaeb94b501ac346622651c452a
We restyle elements with non-animation restyles even if the animations
are throttled.
MozReview-Commit-ID: Exhd4qVx7su
--HG--
extra : rebase_source : 1632bf949bb60a894372a425fd9173e1b718452d
During pre-traversal of EffectCompositor, we call MaybeUpdateCascadeResult(),
which may add new element into mElementsToRestyle, as a result, we may
iterate a mutated mElementsToRestyle. In this patch, we copy the element
which needs update cascade results into another set and traverse this new set
to call MaybeUpdateCascadeResult(). After that, do normal pre-traversal on
mElementsToRestyle.
MozReview-Commit-ID: 3uo6Ec5JNjp
--HG--
extra : rebase_source : 3cdc3c3147f011074a884d85da2655e0ed4a3730
These are interdependent patches of Bug 1334036, which enables off-main thread animations. We add one FFI to get the property id set which overriding animations, so we can make sure the cascade result is correct for off-main thread animations.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1334036](https://bugzilla.mozilla.org/show_bug.cgi?id=1334036)
- [X] These changes do not require tests because we support off-main thread animation only on Gecko, and there are enough test cases there.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5a012cc9b15890fe8ad132e941d8f896b405472c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f72aef04d69022c20bedbbb075d1385bfd15729a
<!-- Please describe your changes on the following line: -->
This is a PR for https://bugzilla.mozilla.org/show_bug.cgi?id=1357663
---
<!-- 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
<!-- Either: -->
- [X] There are tests for these changes, a test case will be landed in web-platform-tests in https://bugzilla.mozilla.org/show_bug.cgi?id=1357663
<!-- 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: 2c3a03b254c696d7be7a3d85ae5957628db63206
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e202adc3bf501a8aa4bd529c323b7ef70c978764
UAOverridesBootstrapper.js is introduced to delay the initialization of
UserAgentOverrides.jsm until the creation of the first nsHttpChannel.
Uninit will be triggered at profile-change-net-teardown because no network
traffice after this point.
MozReview-Commit-ID: F8Lpn6RyZEm
--HG--
extra : rebase_source : 7c3649b50ad8594dc0968961fbbd2766d0d98b0a
system-info might need to be construct while creating nsHttpHandler and it might take up to 30ms.
Lazy loading the DEFAULT_UA can delay the creation of nsHttpHandler after start-up.
MozReview-Commit-ID: FtIpKjcY38r
--HG--
extra : rebase_source : 8061ed3ce6c42955e52f494166958f5b63ab940b
<!-- Please describe your changes on the following line: -->
@jdm @KiChjang First pass at using microtasks to await a stable state. I ran into all sorts of problems to get it to compile, I think it's mainly related to the fact that the microtasks are stored in a `Vec`, which meant the `Runnalbe.handler(self: Box<Self>)` couldn't be called while iterating over the Vec... It compiles now although I haven't run any tests. I'm assuming I'm missing something fundamental and was hoping my changes would highlight the problems I run into, and you had a better idea of how to implement this... Perhaps we shouldn't pass a `Runnable` to `await_stable_state` at all?
---
<!-- 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
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix#15375 (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: f05491166f21879f74758b2f03bbc4c4a4c31eb8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : efc9208e1f0fcd946247ef753d8b7c04105e5b85
This enum type used to contain the result of parsing one CSS source declaration (`name: value;`) and expanding shorthands. Enum types are as big as the biggest of their variant (plus discriminant), which was quite big because some shorthands expand to many longhand properties. This type was returned through many functions and methods, wrapped and rewrapped in `Result` with different error types. This presumably caused significant `memmove` traffic.
Instead, we now allocate an `ArrayVec` on the stack and pass `&mut` references to it for various functions to push into it. This type is also very big, but we never move it.
We still use an intermediate data structure because we sometimes decide after shorthand expansion that a declaration is invalid after all and that we’re gonna drop it. Only later do we push to a `PropertyDeclarationBlock`, with an entire `ArrayVec` or nothing.
In future work we can try to avoid a large stack-allocated array, and instead writing directly to the heap allocation of the `Vec` inside `PropertyDeclarationBlock`. However this is tricky: we need to preserve this "all or nothing" aspect of parsing one source declaration, and at the same time we want to make it as little error-prone as possible for the various call sites. `PropertyDeclarationBlock` curently does property deduplication incrementally: as each `PropertyDeclaration` is pushed, we check if an existing declaration of the same property exists and if so overwrite it. To get rid of the stack allocated array we’d need to somehow deduplicate separately after pushing multiple `PropertyDeclaration`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 60682cf81fe19a82c73dd98ba4c1eebc1dbbfcac
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bf9916ad96bb4c2eedcb7a52110170644c269133
Per https://github.com/rust-lang/cargo/issues/4072 Cargo on Windows is having trouble due to a letsencrypt outage. Our Appveyor CI is busted, as is our Windows builder for any PR that needs to upgrade a package from crates.io.
Source-Repo: https://github.com/servo/servo
Source-Revision: d1e31f7aa46b3b230194de805fff38afcaf9eb68
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a4008e9146c91530c106a904dece15b88e2cbb82
IGNORE BAD COMMIT MESSAGES because something landed and was backed out for no bug number
--HG--
extra : amend_source : 1134c379d1134fe160fd2d889488d07acd9f4177
The mochitest-chrome harness sends a custom "contentEvent" event from redirect.html
to a listener in browser-test.js. It is possible for redirect.html to be loaded
and send contentEvent before the listener is set up in browser-test.js. In the
absence of a better synchronization strategy, redirect.html now retries the send
after a few seconds. If the first contentEvent was received, the second will be
ignored; if the first contentEvent was not received, the second should avoid an
intermittent harness hang and timeout.
There were two issues that prevented the static snapshot toolbar and
real chrome toolbar from staying in sync.
1) When a page would resize such as when going fullscreen, if the
root content document was not scrollable, the animator would not receive
root composition page size updates. The page resize is used by the
animator to hide the static snapshot, so it would remain visible while
the real chrome toolbar would be hidden.
2) Certain places in UI java code would toggle the chrome state directly
instead of going through the animator to change the state.
MozReview-Commit-ID: DCQgRFS0UAO
It's a software memory barrier, and not a very strong one. If the values it is
protecting are Atomic, that provides a stronger hardware memory barrier.
This patch removes it, and changes one of the values it was protecting from
|volatile| to Atomic. (The other value it was protecting was already Atomic.)
Boris Chiou
Mantaroh Yoshinaga
Emilio Cobos Álvarez
Shih-Chiang Chien
Cameron McCormack
Hiroyuki Ikezoe
Manish Goregaokar
Ricky Chien
Gregory Terzian
Servo VCS Sync
Simon Sapin
Brian Stack
Josh Matthews
Wes Kocher
David Anderson
Geoff Brown
Kartikaya Gupta
Mike Cooper
Ryan VanderMeulen
ffxbld
Dão Gottwald
Randall Barker
Iris Hsiao
sotaro
Henrik Skupin
Cervantes Yu
Kris Maglione
Mason Chang
Nicholas Nethercote
Andrea Marchesini