As long as Directory objects can be constructed in the content process, trying
to access the file system conceptually does not make sense because of
sandboxing. The canary in the coal mine for this was tests which started
crashing on Directory construction as we further locked down read access in the
sandbox.
MozReview-Commit-ID: HZitALYpO5H
--HG--
extra : rebase_source : 1f7e0361e40e45a9c23d5d78bdcdc1696d44d298
While MDSM calls MFR::Seek(), MFR tries to do video seek first and then the audio seek.
Video-seek and audio-seek are applied sequentially, and if something wrong in video-seek,
MFR discards the whole seek operation without applying audio-seek.
video | audio |
waiting | waiting | What MDSM receives
-----------------------------------------------------------------------------
X | X | resove mSeekRequest
-----------------------------------------------------------------------------
O | X | reject mSeekRequest with type=VIDEO, error=WAITING
-----------------------------------------------------------------------------
X | O | reject mSeekRequest with type=AUDIO, error=WAITING
-----------------------------------------------------------------------------
O | O | reject mSeekRequest with type=VIDEO, error=WAITING
-----------------------------------------------------------------------------
So, here, AccurateSeekingState::OnSeekRejected() has a unified code to handle
WAITING_FOR_DATA error for both video and audio type, and it uses the
aReject.mType variable to distinguish different types.
But, it mixes the assertions. We should also apply assertions according to the
type that is in concern.
MozReview-Commit-ID: F7RpnFghcKk
--HG--
extra : rebase_source : d18c3197ec2a08f2f184150e0c4a08da200a34b0
Between nsIDocumentObserver::BeginUpdate() and nsIDocumentObserver::EndUpdate(), IMEContentObserver can cache added nodes as a range if they are consecutive nodes. Even if a node is removed, a data node is changed or attribute is changed unexpectedly, IMEContentObserver can post text change of the added node range and handle it normally.
MozReview-Commit-ID: IttDHBkr92Y
--HG--
extra : rebase_source : f0849d5fab0b28bdfa311cf833a216d43b9215d2
IMEContentObserver can reduce the number of times to compute node offsets with caching all added nodes as a range. For that, it needs to know when it starts to update and ends updating the document.
nsIDocumentObserver is a subclass of nsIMutationObserver and IMEContentObserver is a mutation observer of editor's root content. Therefore, if we change IMEContentObserver to a document observer, each mutation observer method needs to check if the change occurs in the observing editor. Therefore, this patch implements document observer as its nested class and manages it as a member of IMEContentObserver.
MozReview-Commit-ID: HPSPfajxjnx
--HG--
extra : rebase_source : fd4bdcc24759040fb6c39317024049a3a924fc67
<!-- Please describe your changes on the following line: -->
Removed the special root browsing context from the constellation.
---
<!-- 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#13994
- [X] These changes do not require tests because this isn't visible from user code
<!-- 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: caa8343e137ab73e046773263dc3ce4b4ebb7b3f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 548e0caed1e409c2284e4418cdebaf388b5c7e27
This is the Servo side change of [bug 1345709](https://bugzilla.mozilla.org/show_bug.cgi?id=1345709).
Source-Repo: https://github.com/servo/servo
Source-Revision: 24e944ad94816e607e833e34095c4f8b8136df4c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9bd6680c1a980543f2ebfc191186cc8d88fb075c
This takes some of the optimizations made to parallel styling in #16971 and applies them to parallel layout. Specifically:
* Reduce the chunk size, to increase chances for parallelism on trees with small fan-out.
* Reduce allocations by using SmallVec.
* Reduce task switching by processing up to one chunk of children within the same rayon task as the parent.
This cuts the "Primary Layout Pass" time in **half** on the MySpace page from [tp5n], and on my other real-world test pages it is a small improvement or close to no change.
[tp5n]: https://wiki.mozilla.org/Buildbot/Talos/Tests#tp5n_pages_set
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they affect performance only
Source-Repo: https://github.com/servo/servo
Source-Revision: c0f3ec87806a0d718d7f9ef1ccb912c78fc482d2
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 473d903f4a7bd5d1403fcb31cbbad6d5570f7ddb
Using nsIProcess has the side-effect of spawning a NSPR process wait loop
thread, which makes it impossible for other IPC code to waitpid on its own
processes, and check their exit status. There are other instances that need to
be changed as well, but this is the one that developers are most likely to run
into.
MozReview-Commit-ID: L0WyOxlXbkk
--HG--
extra : rebase_source : 0b128c187a2d18dd6fb226bb718ede9ce97ece4b
The first time any other code in the parent process uses NSPR (usually via
nsIProcess) to spawn a new process, it spawns a thread to contuously wait for
any child process to exit. This thread winds up reaping our child processes
before we get the chance to wait for them, which leads us to continuously poll
for them to exit.
We don't have a good way to handle this, but checking the error status of
waitpid at least prevents us from failing catastrophically.
MozReview-Commit-ID: 75Z1yUHUmjy
--HG--
extra : rebase_source : db45f781190b6fc84873c32c611134326736a1ba
Activate WebRender output for filters that introduce only one pixel
differences in tests. Since the filters spec does not seem to specify
how color values are rounded, this output should be spec compliant.
