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
We only use nsINamed on runnables for certain kinds of telemetry, and
those kinds of telemetry aren't being gathered on RELEASE_OR_BETA
builds. We effectively make nsINamed::GetName a no-op when we're not
collecting said telemetry. But implementing nsINamed does have a cost:
the vtable of every runnable (and we have hundreds of subclasses of
mozilla::Runnable) will contain pointers for GetName (and extra pointers
for QueryInterface/AddRef/Release), and all those pointers times all
those subclasses adds up quickly. Let's not implement nsINamed when
nsINamed isn't going to be used.
This change saves ~100K of binary size on x86-64 Linux; the savings
should be similar on other 64-bit systems, and ~50K on 32-bit systems.
<!-- 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
A typo meant we were checking the address of mChildCount, not the value.
MozReview-Commit-ID: 7Hit3FBy9pr
--HG--
extra : amend_source : edb85b8e73184e47cd9ff42c0442f89d5f3c5152
Once we've figured out that some task needs to be reposted, there's no
reason to continue scanning the list to find other tasks that need to be
reposted, since the logic in this function just requires one task that
needs to be reposted.
