Rebased due to failing tests on try... built on a failing base.
MozReview-Commit-ID: BiC1pWeml2N
--HG--
extra : rebase_source : 4e57102655d930737950dd571b16632c412e0a3d
This doesn't affect most XBL stylesheets since they load from chrome://
URIs which get loaded synchronously, but it does affect
test_media_queries_dynamic_xbl.html, which would otherwise fail when we
make stylesheet loading asynchronous.
MozReview-Commit-ID: 31y47Z0Oxak
This will allow us to avoid touching the old style system when making
the Servo parses asynchronous, and make it easier to drop the old code
when the time comes.
MozReview-Commit-ID: 5em0PMnb5Nw
Given that we have a SegmentedVector of nsCOMPtrs, it's probably worth
avoiding copying it.
MozReview-Commit-ID: GHyfVLrdnlQ
--HG--
extra : rebase_source : 75df805d8b2df32b76ee77b95ced625f20331744
Gecko only ever had de-zippering for DelayNode.delayTime. It has been decided in
[0] to remove all de-zippering, for consistency.
[0]: https://github.com/WebAudio/web-audio-api/issues/76#issuecomment-107679878
MozReview-Commit-ID: FK9Erwxth05
--HG--
extra : rebase_source : caccac28456191e68c980b12159ed310ce18e149
GetStyleContext can flush. As such, that flush can kill the pres shell, and the
return value could be null. I have no idea why that code was asserting it didn't
happen, but that assert is completely bogus.
Throw instead, just like GetFontParentStyleContext used to do for Gecko.
MozReview-Commit-ID: 5RxDratKumZ
--HG--
extra : rebase_source : 9ffb1f58888504d92915ecd4254847ae2e3f053b
The key here is that we only filter longhands if the shorthand is accessible to
content and vice-versa. This prevents the bug that prevented me to land this
patch before, which was us not expanding properly chrome-only shorthands.
Source-Repo: https://github.com/servo/servo
Source-Revision: a0be3a7fae2730bfef52db94db7f3af14b60be67
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2afb50b62cab334fcec0cdcccd793abca8fdb3ec
This is its only use.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8471011e6b6bd72db68ec9ae21df58ab09f2f6d8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4407223da1f18648537ad75a602434999ce3ee2f
Because of the storage::Service's connection list, it's possible for the
refcount for a non-main-thread Connection to experience transient increases
and decreases at any time, dooming logic in Release() that assumes the
refcount isn't changing.
This patch adopts use of an Atomic<bool> so that we execute cleanup logic
exactly once when the refcount falls to 1 at some point. Care is taken to
ensure that the failsafe Close() occurs on the correct thread.
SpinningSynchronousClose() is still dangerous and can still potentially
nest deeply on the stack. If we see instances of that in the future, we
may want to adopt use of PushEventQueue so that we can avoid re-entrancy
in our event loop spinning.
MozReview-Commit-ID: A835HBec50H
--HG--
extra : rebase_source : af2f63e8f050b7a0275e39f73e59133958e29f19
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19901
Source-Repo: https://github.com/servo/servo
Source-Revision: 23e95906347c4b6d0d1ccd1ce12ff5206c349a9a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 806d322a34be21e05a94e6a7cadbfb78cb0e8b9d