This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
Summary:
When running on pre Oreo devices CrashReportingService (a JobIntentService)
is started as a regular Service.
Return super.onStartCommand(..) to make sure onHandleWork() would be caled.
Reviewers: sdaswani, VladBaicu, jchen
Reviewed By: jchen
Bug #: 1480421
Differential Revision: https://phabricator.services.mozilla.com/D3102
--HG--
extra : rebase_source : 78d83fca65b000a10e2f8b522c8ee57cd364a829
extra : histedit_source : 71a48d23421fec60ded4c0c45c8cafb8927196ab
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
Created specific notification channel dedicated to download progress notifications.
MozReview-Commit-ID: 88vsQiI2L2
***
--HG--
extra : rebase_source : 146563fd14a59299bc9bbba79fc9bdfd9e7ed37f
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
Now that GeckoScreenOrientation generally offers notifications of screen
orientation changes, the PromptService no longer needs to do its own orientation
tracking and require to be fed orientation changes from each activity using it.
MozReview-Commit-ID: K7KbDsQip7b
--HG--
extra : rebase_source : 72164b6e6b9c8e1a2f31a33db9b8da7d457739a9
As of bug 1475875, cached screen data is now held by Gecko, so
- we no longer need to cache the screen size (retrieval of which can be
expensive when called en masse, as required e.g. by font inflation) within
GeckoAppShell, and
- we need to trigger a refresh of that data instead when the activity
orientation changes.
MozReview-Commit-ID: JsY6sBCcOih
--HG--
extra : rebase_source : a99e4688d6724e5b73b748078f51cf6a6268733d
By moving the calls to GeckoScreenOrientation.update() into GeckoView, any app
using a GeckoView will automatically update the screen orientation in Gecko,
too, without any further action being required by the embedding app.
MozReview-Commit-ID: 5s5NEJcuS0p
--HG--
extra : rebase_source : 2b61942672d27453a936174c16f843109c9e36ba
The call to mSession.transferFrom(ss.session) in the line above also transfers
the window from ss.session into mSession, which means we subsequently won't be
able to retrieve a runtime from ss.session any more, thereby defeating the goal
of calling mRuntime = ss.session.getRuntime().
This case is encountered e.g. when the containing activity is destroyed and sub-
sequently recreated after a configuration change that isn't handled by the app,
e.g. screen rotation in the GeckoView example app.
MozReview-Commit-ID: 5YGskdLZWqw
--HG--
extra : rebase_source : e9b5a7478cfb8a9ad44c149e3ba1532f22ab4086
Once responsibility for notifying GeckoScreenOrientation of potentially changed
screen orientations moves from GeckoApp into GeckoView, the former will no
longer be able to benefit from the return value of calling GeckoScreen-
Orientation.update(), indicating whether the orientation actually changed or in
fact remained the same.
GeckoApp however requires that information in order to reset/refresh parts of
the UI when the orientation changes, and since GeckoScreenOrientation is already
doing all the work of tracking screen orientation changes, we don't want to have
to partially duplicate those efforts again in GeckoApp.
Instead, we introduce a mechanism for GeckoScreenOrientation to notify
interested parties on the Android app side as well.
The GeckoScreenOrientation.update() call in GeckoApp.onResume() is removed
completely (as opposed to merely removing the refreshChrome() bit) at this stage
already because it is unnecessary. If any screen rotation happened while the
activity was in background, it will receive an onConfigurationChanged() call
anyway before being resumed again.
MozReview-Commit-ID: Ila1evcj8Ud
--HG--
extra : rebase_source : 345c838325264399cc7f7829cc587faf7e9cc756
This permission is needed on API26+ to be able to install app updates but also
other downloaded APKs.
MozReview-Commit-ID: Lk0uqBAJ5BH
--HG--
extra : rebase_source : 5f31cfd06c2205cd2a96ac68ba19b697d49ae75c
This alters nsILoadURIDelegate.loadURI() to return a Promise rather than spinning the event loop to synchronously return a boolean, and alters nsDocShell::InternalLoad to allow for those changes by re-calling itself if necessary based on the resolution of the promise.
Multidex will now be enabled for all builds, not just for the _local_ ones.
Also added the 'ads-identifier' library needed for the builds with the
MOZ_INSTALL_TRACKING flag case in which the dex limit would be reached.
MozReview-Commit-ID: FRTXBD9Kc6T
--HG--
extra : rebase_source : c73a0a48d355edbe2080b14ceeb2f99609a45d7c
This happened whenever starting to cast a video and loading the media failed.
MediaStatus in this case would be null and querying it would throw a
NullPointerException.
Avoiding this query when the MediaStatus is null lets the normal execution flow
continue and if loading media failed casting will fail gracefully.
MozReview-Commit-ID: 8ZOqr1FO1Dt
--HG--
extra : rebase_source : 905b7e83bc7265fe8312509dfc5aa6274dd89c5c
In order to use DOMLocalization from C++ we need an XPIDL interface.
mozIDOMLocalization exposes the class and functionality allowing DocumentL10n to hook into it.
MozReview-Commit-ID: GPMhw61LPEg
--HG--
extra : rebase_source : 65d6e2b84379e78201f0c8b674630d1f485aaf8c
The 'dataType' parameter to nsISearchEngine.addEngine is now obsolete.
MozReview-Commit-ID: CTe26M0j4xa
Differential Revision: https://phabricator.services.mozilla.com/D2778
--HG--
extra : moz-landing-system : lando
Fixed the issue where we it was trying to parse a drawable instead of an id from parcelable.
MozReview-Commit-ID: IEgmAT39JiQ
Differential Revision: https://phabricator.services.mozilla.com/D2924
--HG--
extra : moz-landing-system : lando