Because the emulator is super slow, it would need longer time to wait for the tab's playback status changed.
MozReview-Commit-ID: CLUimz6pF26
--HG--
extra : rebase_source : 11324f446dee72e813e901579614659e16d0d4d9
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
Added gDevTools.getTheme() to provide the theme name, and a gDevTools "theme-changed"
event to provide a notification when the theme is changed.
MozReview-Commit-ID: EeUAmtyPpUy
--HG--
extra : rebase_source : 38515c6fb4d4294aa20d862da0c1bb96f17cd99a
The previous version of this test assumed that it was in control of all
processes (except for a single one that was hanging around). That meant that
changes to the environment, such as running it on a different branch could
cause it to fail. Now we explicitly test that creating new tabs creates a new
content process (and that the final tab creation *doesn't* do so) with a
sanity check that new ContentParents don't reuse the same underlying OS
process. Because we're now explicitly testing what we want, this works whether
the current branch holds a random extra process alive or not.
MozReview-Commit-ID: CNgLGL32Iog
--HG--
extra : rebase_source : f27d132d00bdd94d7034cc63c83bbacfe04bde0c
