That ChannelLayout uses an AutoTArray internally makes XPCOM report them as leaking when declared as static.
They weren't use outside of ChannelLayout anyway so they can be removed.
MozReview-Commit-ID: KVqdjzvL8pr
It makes no sense to have a case for those as the data structure used (a bitmask) do not allow to represent this channel layout (a channel can only be present once). As such it was a non-functional layout
MozReview-Commit-ID: FjA0fojFcJp
This makes it for future easier conversion for the FFmpeg and Windows WMF decoder, so that we can use their channel map directly.
Also introduce a difference between 2F2 and QUAD, cubeb supports will be added in a future change.
MozReview-Commit-ID: L5NkjeuGslI
nsBaseWidget::BoundsUseDesktopPixels() states that window types before
eWindowType_popup take desktop pixels rather than device pixels for
parameters of Move and Resize.
Cocoa widget seems to treat all of them as desktop pixels, and sheet is
one of the window types that it can actually open, so it should be put
before popup so that BoundsUseDesktopPixels() is correct on that.
MozReview-Commit-ID: FPqOoUQlQCy
--HG--
extra : source : 1d1f62a81d9fc059af9038eebc64256aeba397d3
OSX jittests have been running as a no-op for a while, due to a mozharness mis-configuration.
This fixes the configuration so that the test suite actually runs.
This is deprecated and there are no consumers that use
IndexedDB.jsm with the storage option.
--HG--
extra : rebase_source : ebf55265affe5d01c1934de5593de420b5405033
This patch was automatically generated by running the following commands:
$ cargo update -p cc
$ ./mach vendor rust
MozReview-Commit-ID: 51NVIhtno6O
--HG--
extra : rebase_source : e4273dccdf531dfadd01c82e3d1131d509f9ffc7
<!-- Please describe your changes on the following line: -->
Complementary to https://github.com/servo/rust-mozjs/pull/404.
Removing `Heap::handle_mut` didn't warrant any changes on Servo side, and so the changes here are only to fix compilation with `Heap::handle` being now marked as `unsafe`.
The main idea is that we can't hand out handles to heap values themselves, since they're not guaranteed to be rooted, but it's safe to do when we are - hence why the safe impl on `RootedTraceableBox<Heap<T>>` and why it's safe to use inside structs that hold a Heap and are `#[must_root]`.
---
<!-- 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
- [X] These changes do not require tests because the compiler forces correctness here.
<!-- 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: 18ef5874dd3e11551e2f9503746540847eeb974c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 51f863c54f4fa1d159691fea3ae5b9ff76e004b9
The old style system used FlattenedTreeIterator for lazy frame construction.
That could not find native anonymous nodes, so we had to construct eagerly in
native anonymous subtrees. Servo uses StyleChildrenIterator for the same
purpose, and that knows about native anonymous content, so we can now do lazy
construction for it.
Also, not check the container to do lazyFC on the children, it's no longer
necessary to check for anon content, and the reason we check for XUL is because
of XBL bindings, and those are loaded for the parent already, if we're about to
construct frames for the children.
Also, assert more tightly, we don't insert NAC lazily, that makes no sense.
Well, to be fair editor does insert anonymous nodes lazily sometimes (see al the
ManualNAC machinery), but it goes through the PostRecreateFramesFor path, not
through ContentInserted / LazyFC.
MozReview-Commit-ID: 2TmRNgpWaM
Summary:
I can propagate the error up if needed, but looks like the code should cope with
it just fine with this change.
Reviewers: kats
Bug #: 1446108
Differential Revision: https://phabricator.services.mozilla.com/D794
MozReview-Commit-ID: Dm6EKIC6F5i