Since we make 'image-orientation' and 'paint-order' properties animatable,
remove test fail annotations from meta in wpt.
MozReview-Commit-ID: JRMe8wSxydg
--HG--
extra : rebase_source : f11a0d0d08fd743d373021f498f892a2d07cfb23
The generic fallback MOZ_FALLTHROUGH definition is insufficient for GCC 7 and
above, resulting in --enable-warnings-as-errors builds failing.
The check for clang support is changed to use the __has_cpp_attribute macro,
which is more robust than checking the __cplusplus version.
Also, MOZ_FALLTHROUGH is now only defined in C++ code, since GCC errors out if
it encounters a scoped attribute being used with __has_cpp_attribute in C code.
No C code uses MOZ_FALLTHROUGH or derivatives at the moment.
MozReview-Commit-ID: 4nKFBRD5jSF
--HG--
extra : rebase_source : 0c37ae39c806ca24a3271d3ec19531dd16e05daf
<!-- 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
<!-- Either: -->
- [ ] There are tests for these changes. The test code is patch 3 in https://bugzilla.mozilla.org/show_bug.cgi?id=1386963
<!-- 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: 50c9797ddd7b206c96f9436c634d915efe4acc17
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 596da466caf6c5be55db82c0734ee90398f933ec
AudioEndTime() returns 0 if the media sink is not started. This is wrong
because the audio/video end time should be at least the current position
to ensure playback won't go backwards.
http://searchfox.org/mozilla-central/rev/bbc1c59e460a27b20929b56489e2e55438de81fa/dom/media/MediaDecoderStateMachine.cpp#2009-2012
This fix the case where we wrongly set playback position to 0 after seeking
to the end of resource.
MozReview-Commit-ID: 2VnTcqyIvoJ
--HG--
extra : rebase_source : 3abb59053952c018b1bff8c442450e98845a4947
extra : source : 3dc1a61d32e5be587f5f6892217fe9fe25ca533b
Since inf can be encoded in MDSM::mDuration, we don't need an additional flag
in MediaDecoder to indicate 'infinite' anymore. Note duration change from infinite
to finite is handled by MDSM, so we can remove the explicit calls to SetInfinite(false).
MozReview-Commit-ID: EoxwZJzPAJl
--HG--
extra : rebase_source : 669d7ed5b99a89b1827f60f89e0a21f08a18dedd
extra : source : a30b614784afe8772b2212728c1e4a2eac67f94b
We pretty much rewrite the whole logic of duration calculation of MDSM.
The new logic is much simpler for we have only one duration to manage
which is mDuration. Below is the details of the code changes:
1. remove the mExplicitDuration mirror since it should be handled in MediaDecoder.
2. remove mObservedDuration and mDuration will take its place.
3. mDuration is updated from:
a. metadata
b. playback position as playback progresses.
c. buffer ranges.
4. change mDuration to be finite when playback reaches the end.
MozReview-Commit-ID: 1EmlWvmw1R2
--HG--
extra : rebase_source : 54110160af6e167cdb59b24e1c6be7901bf56269
extra : source : 6325e6ae2319cae62e4c08cfc38706c9ac056842
We will let MediaDecoder do the final adjustment.
MozReview-Commit-ID: NmPD3Cgsta
--HG--
extra : rebase_source : 97f15f7ec330706edb7651c52e2eef128ac427f6
extra : source : 45e94e9edc423de6d53776b70c9c25cc9f40ce30
The implementation will be shared by most of the sub-classes except OggDecoder
which needs to call demuxer->SetChainingEvents().
http://searchfox.org/mozilla-central/rev/f0e4ae5f8c40ba742214e89aba3f554da0b89a33/dom/media/ogg/OggDecoder.cpp#25
This helps reducing code changes whenever we add a field to MediaFormatReaderInit.
MozReview-Commit-ID: 5K8NY1oxol4
--HG--
extra : rebase_source : 7bc2a71ad9bd982ada51fd28d6a5b7c6f1d7395a
extra : source : cccd49795938ce53cd8eee597ec0ea4859543c37
Since Ahem.ttf is valid now, we should pass wbr-element.html on Windows.
Also, mac doesn't pass this test because MOZ_BUNDLED_FONTS isn't set on macOS build.
MozReview-Commit-ID: 5ylfn8525j7
--HG--
extra : rebase_source : 9e894b4edea52a75c9a13c523679039d7ef0d59c
Ahem.ttf is copied to $(DIST)/bin/firefox/fonts, but this file is broken due to text mode copy. So we should use binary mode instead.
MozReview-Commit-ID: KP7yNyPiejU
--HG--
extra : rebase_source : 2de749f458a6d4650f9044f1912ff97835c5b795
The lesson learned from bug 1356926 and bug 1386588 is that the version
of gcc used to build clang matters, and that we can't bind the version
we use to build clang to the version we use to build Firefox.
In some cases, we can end up linking some things with
--static-libstdc++. The notable (only?) example of that is for the
clang-plugin, and that happens because it gets some of its flags from
llvm-config, which contains --static-libstdc++ because clang itself is
built that way.
When that happens, the combination of --static-libstdc++ and
stdc++compat breaks the build because they have conflicting symbols,
which is very much by design.
There are two ways out of this:
- avoiding either -static-libstdc++ or stdc++compat
- work around the symbol conflicts
The former is not totally reliable ; we'd have to accurately determine
if we're in a potentially conflicting case, and remove one of the two in
that case, and while we can do that for the cases we explicitly know
about, that's not future-proof, and might fail just as much in the
future.
So we go with the latter. The way we do this is by defining all the
std++compat symbols weak, such that at link time, they're overridden by
any symbol with the same name. When building with -static-libstdc++,
libstdc++.a provides those symbols so the linker eliminates the weak
ones. When not building with -static-libstdc++, the linker keeps the
symbols from stdc++compat. That last assertion is validated by the
long-standing CHECK_STDCXX test that we run when linking shared
libraries and programs.
That still leaves the symbols weak in the final shared
libraries/programs, which is a change from the current setup, but
shouldn't cause problems because when using versions of libstdc++.so
that do provide those symbols, it's fine to use the libstdc++.so version
anyways.
This method can be extremely hot, so we need to remove all sources of XPCOM
overhead from it. This includes the usages of weak pointers (thanks to the
previous parts), refcounting, and QueryInterface.
I kept the callers hold the selection controller alive by assigning the
return value to an nsCOMPtr in places where the methods called on it could
have a remote chance of messing with the lifetime of objects.
