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
MozReview-Commit-ID: LVML7EZaSYD
In non-e10s AccessibleWrap::HandleAccEvent, we special case our handling of
CARET_MOVED and FOCUS events with a call to UpdateSystemCaretFor. In e10s mode
we were not doing the same thing for proxied events sent from content. This
threw JAWS for a loop and presumably messes up other ATs as well.
This patch modifies the IPDL messages for these two events so that we may
send the caret rect along with the event, thus allowing us to update the
system caret for proxied events as well.
--HG--
extra : rebase_source : e1502c12b038739520afd5c7078d011e25ea669e
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
We should only render the Subtitles/Captions cue on the screen. In addition, rename the activeCues to showingCues.
Because the meaning of "active" and "showing" are different. Showing means we can see the cue on the screen, active means the current playback time touches the cue.
MozReview-Commit-ID: 1BfHhxFXBDP
--HG--
extra : rebase_source : 2c4d6b0b052758f1bb01a7794365bf75b556304c
If the browser is in fullscreen mode and Set Window Rect is called
we need to exit fullscreen mode and then continue to manipulate the
browser.
As described in https://w3c.github.io/webdriver/webdriver-spec.html#set-window-rect
Step 10
MozReview-Commit-ID: 5ixhGOXVBE4
--HG--
extra : rebase_source : be2b8b6da5cf78c6263502a6cb422e2de81c742d
This event is no longer necessary, since checking nsITabParent.hasPresented is enough to know
if we need to blank out the tab or not.
MozReview-Commit-ID: 445XMqhorxC
--HG--
extra : rebase_source : 1a05de827502c409d979a621471978b08ce39fb2
The FX_TAB_SWITCH_SPINNER_TYPE probe isn't necessary anymore since showing
a tab switch spinner for tabs that haven't presented is no longer possible.
MozReview-Commit-ID: 9q6nbuzygpY
--HG--
extra : rebase_source : 90b82da16ffb56ed4e59aa085c536feb23a5e139
browser_tabSpinnerTypeProbe.js isn't necessary anymore since it should not possible to show
spinners for tabs that have never been presented.
MozReview-Commit-ID: AD4ppdhe346
--HG--
extra : rebase_source : 188293c33b733bda34f2d0fbac39198b456583ff
nsITabParent.hasPresented already encapsulates the case where the TabChild might
not have been constructed, since such a tab could never have been presented to
the user. If we're async tab switching to a tab that's never presented before,
we blank it out initially while waiting for its layers.
MozReview-Commit-ID: CL76wLmjRxc
--HG--
extra : rebase_source : ebdfc62ba924092f7a9356f83bc74c504a3f487d
Some manifest entries (e.g. skin or locale) have an attached identifier,
and there can be different entries with different identifiers for the
same chrome name. The change from bug 1366169 would consider those as
errors, while they are the expected configuration.
--HG--
extra : rebase_source : ceb08da909121a2ac0a2cdaba7970e4594dde09f
CERT_CreateSubjectCertList is not an inexpensive function call, since it
enumerates the certificate database (i.e. reads from disk a lot). If we're
verifying for a TLS handshake, however, we should already have in memory a
certificate chain sent by the peer (there are some cases where we won't, such as
session resumption (see bug 731478)). If we can, we should use those
certificates before falling back to calling CERT_CreateSubjectCertList.
MozReview-Commit-ID: ASjVGsELb1O
--HG--
extra : rebase_source : 1efc635d4a98079c87f77ef3794e4b2f20eec59f