The APZUpdater class holds the methods that are to be run on the updater
thread. Note that there are a few differences between the APZSampler and
APZUpdater classes - most notably, APZSampler no longer has a
"RunOnSamplerThread" function because there should never be any need to
dispatch runnables to the sampler thread. There is still a
RunOnUpdaterThread in APZUpdater, as well as a mechanism for dispatching
runnables to the controller thread via the updater thread.
MozReview-Commit-ID: LLVWzRyhYWl
--HG--
extra : rebase_source : d3d2ae18b40f24473cab5567a48b67b8f478a733
…reak servo
<!-- 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: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix https://github.com/servo/rust-mozjs/issues/153
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because this is just migration to a lifetimed API
<!-- 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: 914952487bcbba0a31db8aefc4a9487903721959
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 42a821264f87e446c0ea44718656b99fb2c3541c
window.sizeToContent() apparently interacts poorly with windows that have a
persisted size (see bug 90276, which is a 5-digit bug that hasn't been touched
in over a decade). As a workaround, don't persist the certificate exception
dialog's size. This means we have to call window.sizeToContent() more often and
unfortunately results in the window growing and shrinking again on Windows, but
at least it will always be the "right size" for its content.
MozReview-Commit-ID: 9UT3X8IEqZg
--HG--
extra : rebase_source : 9d968748bd77328eea4ae11e1ae746de9401fb4d
In some cases we need to export other environment variables, so make it
easier to track them.
MozReview-Commit-ID: 82OOlRTdhH0
--HG--
extra : rebase_source : 1256098d1bdae9ab13bfe5a149ee33d509ead3f4
It looks like TabChild::RenderLayers already does the work of suppressing the displayport,
so all of the suppression and bookkeeping that AsyncTabSwitcher is doing is superfluous
and probably opening us up to weird graphical glitches (like the one associated with this
bug).
MozReview-Commit-ID: 5qIVguSMsnr
--HG--
extra : rebase_source : 35f944a324415401c4a28ed0006baf9361ef73c8
Since |mach xpcshell-test| was already defaulting to the 'mach' format, this will be a no-op
for most people. For anyone who had:
[test]
format=tbpl
in their machrc file, this will start working for xpcshell tests.
MozReview-Commit-ID: LwIlh0lefN6
--HG--
extra : rebase_source : 5231e18c57e1aa3aacbc6d332127b7c9e2f9111f
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
I'm not adding a patch to security/sandbox/chromium-shim/patches for this,
because we need to get this fixed ASAP, certainly before we take another update.
Functions in APZSampler that are only invoked without WR (e.g. from
AsyncCompositionManager only) can be asserted as running on the sampler
thread. Functions that are invoked with WR need to be bounced onto the
sampler thread. In all cases the functions are called from the
compositor thread, and so we assert that as well.
MozReview-Commit-ID: JPgGlgUUsgg
--HG--
extra : rebase_source : 8b950d3386e1e64e766b76edaa7894b251fb8664
The methods on PAPZCTreeManagerParent are always invoked on the
compositor thread, which currently is always the same as the sampler
thread. When it does RunOnControllerThread calls, there is an implicit
ordering with respect to the sampler thread, because the controller
thread messages are always dispatched *from* the sampler thread.
When we move the sampler thread to be the render backend thread, we have
to preseve this implicit ordering, but we have to make it more explicit.
For example, if a content process sends a layers update followed by
a SetTargetAPZC message, it expects that the APZ will process them in
that order, as the SetTargetAPZC might refer to a scrollframe that was
just layerized. Currently, both these messages arrive on the compositor
thread; the layers update is processed directly as the compositor thread
is the sampler thread, and then the SetTargetAPZC message is bounced to
the controller thread. However, if the compositor thread is not the
sampler thread, then we would bounce the layers update to the sampler
thread, and bounce the SetTargetAPZC to the controller thread,
introducing a race. If SetTargetAPZC runs first bad things happen. The
solution in this patch is to bounce the SetTargetAPZC to the sampler
thread as well, so that it gets bounced to the controller thread only
after we have processed the layers update.
This patch accomplishes that by introducing a method on APZSampler that
does this "double bounce".
MozReview-Commit-ID: KI9wQQ9PZT4
--HG--
extra : rebase_source : 79d0d36a649f11cc795148cc86539a526c8beeae
This is functionally a no-op (it just moves the thread-bouncing code
from inside APZCTreeManager::SetLongTapEnabled to the call site in
APZCTreeManagerParent. The other call site, in
widget/android/nsWindow.cpp, is already known to be running on the
controller thread (which would be the Java UI thread in that case).
This makes the code in APZCTreeManagerParent more consistent and
simplifies the next changes.
MozReview-Commit-ID: 8VfEDVVFNl8
--HG--
extra : rebase_source : 02225ed5b80129a1d18b429eff93866a33d4ea86
Note that this also makes the utility functions instance methods,
because each APZSampler might have a different sampler thread instance.
MozReview-Commit-ID: 9dY8ZzVX6lR
--HG--
extra : rebase_source : 4dd58400aee5d9f2063abe0a912488b28ff74f9f
The spec doesn't say CSSKeyframesRule needs to inherit CSSGroupingRule.
It inherited GroupRule because Gecko's keyframes rule implementation
relies on that to manage its children.
MozReview-Commit-ID: CnVP2tozwQU
--HG--
extra : rebase_source : 63c61d7b7d003ff82bd73e183516f6076a2dafb6
For part 2, where CSSKeyframesRule will inherit directly from Rule while
it is parent rule for its CSSKeyframeRules.
It seems there is nothing relying on mParentRule being a GroupRule so we
can just change it.
MozReview-Commit-ID: Cyte6h3Q2LB
--HG--
extra : rebase_source : 01ac2ab201a1438aa73eadc5cce0ea67e164ecce
This fixes#13464 by rethrowing exceptions from parsing JSON.
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #__ (github issue number if applicable).
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: 25dcd0ecfd4cb7a844f00696730cb0d3ab4b198c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6d221fe0611ecdbea8ff6c2f32d8d7621ddf27b7
<!-- Please describe your changes on the following line: -->
These changes are the servo changes to allow the measurement of DOM objects with the ObjectPrivateVisitor API. Two new functions have been added MemoryReporter and get_size, which are passed as function pointers to two updated mozjs functions. Currently these changes rely on a branch version of mozjs, which has an [open pull request](https://github.com/servo/rust-mozjs/pull/409).
---
<!-- 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#7084 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] 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: 339146ae1566fc35e47ccc4fba1471a9123d039d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 61df47854e0fd7725b25202c298646f52f5b4b4b
