Right now, Fennec builds against Android SDK 23. ExoPlayer expects to
build against Android SDK 24 (but targets Android platform 9 and
above).
We replace constant values introduced in Android SDK 24 with values manually copied from
https://developer.android.com/index.html and we cull unused code from CryptoInfo.java.
Together, these changes allow ExoPlayer to build against Android SDK 23.
Bug 1365543 tracks reverting these changes once Bug 1259098 lands and Fennec builds against Android SDK 24.
MozReview-Commit-ID: 7wz5qIROCN
--HG--
extra : rebase_source : 556168e1d07a2a699952262cd4abba99acd59874
ExoPlayer is an application level media player for Android. It provides an alternative to Android’s MediaPlayer API for playing audio and video both locally and over the Internet. ExoPlayer supports features not currently supported by Android’s MediaPlayer API, including DASH and SmoothStreaming adaptive playbacks. Unlike the MediaPlayer API, ExoPlayer is easy to customize and extend, and can be updated through Play Store application updates.
ExoPlayer is licensed Apache 2.0, so it's fully compatible with Mozilla's MPL.
The import is the contents of d979469659/library
without {ui/,dash/,smoothstreaming/,all/} subdirectories.
MozReview-Commit-ID: 6ut5O3Yb5Tp
--HG--
extra : rebase_source : f05118ecbc9d0506f0411f160b2d14ea2508c229
A feature flag named MOZ_ANDROID_HLS_SUPPORT is added.
HLS (HTTP Live Streaming) is supported on different browsers on mobile devices.
By integrating ExoPlayer's components into Fennec, we're able to play media via HLS on Fennec.
MozReview-Commit-ID: Igubn98UPjh
--HG--
extra : rebase_source : a9740cda5e67c1a1d3ce714761bf33e441060fd8
This makes will-change:contain work correctly.
<!-- 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
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] 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: 96d6b30eff3c0449726b3ea49140b13c7dd7f1f8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 11c8a2b95dd279f3eaa8cc3f5c2de1b45f9cb47c
We no longer support decoding non-EME audio via GMPs, so it's not possible
for a GMP to be used for decoding content that passes through a WebAudio
BufferDecoder. So we don't need to keep the GMPCrashHelper around in the
WebAudio code. If EME content is being used, there will be a crash helper on
the MediaKeys object anyway.
MozReview-Commit-ID: BThxnTANSTD
--HG--
extra : rebase_source : 2c2ce4e982dcef6e3985c426386974083505c953
After adopting the new thread model for safebrowsing, we will create a new
lookup cache for update so we can still check lookup cache at the same time.
Prefix set, completions will be generated when we open the new lookup cache
but it won't include cache, so we will loss cache after that.
This patch will copy cache data from old lookup cache to new lookup
cache while update.
MozReview-Commit-ID: L0WpiHOGIGm
--HG--
extra : rebase_source : ebaf249535561b87a983a3f24dacb8fbab7c096e
This fixes a quality issue with the surround-sound encoder
handling loud signals.
MozReview-Commit-ID: EkzEqs9io6N
--HG--
extra : rebase_source : 15e31af6865f0726beae0a988cb986bd182bac8e
See also pt. 4. We are moving app menu notification state
into a jsm since it is not specific to one window and this
simplifies work for the new app update UI.
MozReview-Commit-ID: InEp5b0y2n0
--HG--
extra : rebase_source : afe4870fe01d64c7b870ddf568c525e6b12f27b2
See also commit message for pt. 4. We're moving app menu
notification state into a jsm.
MozReview-Commit-ID: 3RehYcHyfLu
--HG--
extra : rebase_source : 56d364ce6fd3afe54fc1be797c3efb3dda7623aa
We are moving app menu doorhangers and badges out from window-
specific code into a jsm, in order to simplify the work that
the new app udpate UI has to do. Since browser-addons.js also
consumes the badge system, this ensures that it also uses the
jsm store.
MozReview-Commit-ID: Fb5Fsja0RcA
--HG--
extra : rebase_source : c979e361aba54692f89e79317e4958b65c8b4722
Tried to do the reverse order (move files then edit), but
reviewboard didn't seem to like me trying to undo what I had
already done. This should at least make the diffs clean though.
MozReview-Commit-ID: Ibcgg2Mc6MT
--HG--
rename : browser/base/content/test/appUpdate/downloadPage.html => toolkit/mozapps/update/tests/browser/downloadPage.html
rename : browser/base/content/test/appUpdate/head.js => toolkit/mozapps/update/tests/browser/head.js
rename : browser/base/content/test/appUpdate/testConstants.js => toolkit/mozapps/update/tests/browser/testConstants.js
extra : rebase_source : db886e032b68f73c561ad7bdaa7e0d4ee4cf0e1a
Since we now have a store of notifications that is global across
all windows, it no longer makes sense to consume the API from
within browser.js. This patch moves the browser.js logic out into
a jsm file that is wired up through nsBrowserGlue, such that it
will be lazily instantiated on the first update event it would
receive[1].
We decided to move this into toolkit, as this piece of the
system is fairly generic and shouldn't differ between
applications.
[1]: There is a change to nsBrowserGlue to use "global[module]"
instead of this[module]. This mirrors the code for all the other
types of notifications, and I suspect it was just a latent bug,
since the original diff that includes this line makes no use of
it.
MozReview-Commit-ID: 8EQdM9BOpgl
--HG--
rename : browser/base/content/test/appUpdate/.eslintrc.js => toolkit/mozapps/update/tests/browser/.eslintrc.js
rename : browser/base/content/test/appUpdate/browser.ini => toolkit/mozapps/update/tests/browser/browser.ini
rename : browser/base/content/test/appUpdate/browser_updatesBackgroundWindow.js => toolkit/mozapps/update/tests/browser/browser_updatesBackgroundWindow.js
rename : browser/base/content/test/appUpdate/browser_updatesBackgroundWindowFailures.js => toolkit/mozapps/update/tests/browser/browser_updatesBackgroundWindowFailures.js
rename : browser/base/content/test/appUpdate/browser_updatesBasicPrompt.js => toolkit/mozapps/update/tests/browser/browser_updatesBasicPrompt.js
rename : browser/base/content/test/appUpdate/browser_updatesBasicPromptNoStaging.js => toolkit/mozapps/update/tests/browser/browser_updatesBasicPromptNoStaging.js
rename : browser/base/content/test/appUpdate/browser_updatesCantApply.js => toolkit/mozapps/update/tests/browser/browser_updatesCantApply.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadCompleteSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadCompleteSize.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadPartialSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadPartialSize.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadSizes.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadSizes.js
rename : browser/base/content/test/appUpdate/browser_updatesCompletePatchApplyFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesCompletePatchApplyFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesCompletePatchWithBadCompleteSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompletePatchWithBadCompleteSize.js
rename : browser/base/content/test/appUpdate/browser_updatesDownloadFailures.js => toolkit/mozapps/update/tests/browser/browser_updatesDownloadFailures.js
rename : browser/base/content/test/appUpdate/browser_updatesMalformedXml.js => toolkit/mozapps/update/tests/browser/browser_updatesMalformedXml.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailureWithCompleteAvailable.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailureWithCompleteAvailable.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailureWithCompleteValidationFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailureWithCompleteValidationFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchWithBadPartialSize.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchWithBadPartialSize.js
extra : rebase_source : 24048650b23eff0a1da9679d1e9b5e1db1900287
Right now, app menu doorhangers/badges have their state managed
directly inside panelUI.js. This is problematic because these
doorhangers and badges usually have to do with Firefox itself,
and not the specific window that's showing them. Accordingly, the
simplest solution was to move panelUI.js's notification state out
into a jsm file, which will fire notifications that all panelUI
instances can listen to.
MozReview-Commit-ID: 7b8w1WsQ29p
--HG--
extra : rebase_source : 23575df8176b862ec0e6a039173b105c45c76de9
When we send out a prefetch request, we act as if the load came
from one of the possibly many documents containing <link> element
for the given URL. The docgroup assigned to this request is
derived from this document. Later, when the load finishes, the
OnStopRequest code runs in a runnable labeled with this
docgroup. OnStopRequest dispatches a load event to *all* the link
elements, including some that might be in different docgroups
from the OnStopRequest runnable. This generates an assertion.
To fix this, I decided to dispatch the load events
asynchronously. I'm hoping the extra round trip through the event
loop shouldn't hurt us too much since I doubt anyone actually
listens for these events.
MozReview-Commit-ID: FTkjuHO7RFp
Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.
