In case we change our thinking on launching of downloaded files and start using
content:// URIs for that case as well, we already allow our FileProvider to
generate URIs for the whole file system using <root-path>. This is because users
can in principle move our download directory to an arbitrary location on the
file system as long as it is accessible to Firefox. However not all of these
locations (e.g. on a removable SD card) can be specified through the other
methods of specifying available files for a FileProvider, so only the <root-
path> option remains.
MozReview-Commit-ID: 2UStBlU4JsG
--HG--
extra : rebase_source : 2c1828e063c1b3e772ac20c415fd34d0da1c24a6
Now using the the TYPE_APPLICATION_OVERLAY window type to display alert windows for devices running on Android O.
MozReview-Commit-ID: 7pdquyowbsB
***
***
--HG--
extra : rebase_source : fc07c2c2a34fe53583ba59fc27a7a6f75f4a812b
Bug details:
The problem stemmed from the now called GeckoPreferences.trySwitchToHeader(int id) which could be called with an invalid id, constant with the same value as the id of the last available setting.
(GeckoPreferenceFragment().getHeader() would return valid ids only for preference screens that are launched directly. Otherwise it would return: -1)
By chance the id for the last available setting - vendor was not set and so Android saw it with an invalid header id: -1.
GeckoPreferences.trySwitchToHeader(int id) would just switch to showing the vendor setting because that is what he has been instructed to whenever the user tried to access other settings than the ones which can be launched directly.
Cleaned the code a bit:
- renamed GeckoPreferences.switchToHeader(..) to trySwitchToHeader(..) as it won't always perform that action
- removed the call to activity.showBreadCrumbs(..) as in my tests it didn't have any effect and the documentation says "This will normally be called for you".
Tested on An Android 8 tablet, on an Android 8 phone, on an Android 5.0.1 phone and all works ok.
MozReview-Commit-ID: 2sbfcuRHgZd
--HG--
extra : rebase_source : 51f4629e89846d01224a0cd7dd8b3fba93657f40
Currently, if the "layout.accessiblecaret.allow_script_change_updates"
pref is false, we always hide accessible carets when the selection
changes due to JS calls (e.g. setSelectionRange(0, 1)). If the pref is
true, instead, we update the accessible carets if they are already
visible. In either case, we never show the carets if they're invisible.
However for testing purposes, it's useful to make it so we do try to
show the carets if they're invisible. This patch replaces that pref with
the new integer pref "layout.accessiblecaret.script_change_update_mode",
which can be 0 or 1, which correspond to the old pref, or the value 2,
which introduces this new behavior of always showing the carets.
MozReview-Commit-ID: Bf1gPpIzcyb
--HG--
extra : rebase_source : 5eaba6c18d800da425d5e21f61af880678d7fe3c
Added contentDescription strings for QR Code and Voice Input
MozReview-Commit-ID: 6tpoewhPxev
--HG--
extra : rebase_source : 3ed1f0263f108ad63131f99168ee9879f83fbdb2
Strings needed for this feature were added in a separate bug - 1445798 which were causing Lint errors.
When this feature will land there will be no need for the suppression.
MozReview-Commit-ID: IhtTS8rHLwz
--HG--
extra : rebase_source : 6c09445f7f8c6f6fb565f41e57f666e9cfc26627
The behavior of this new preference is dynamic in that:
- it will be hidden if LeanPlum is not available for the device
- it will be toggled off and disabled if Health Report is disabled by the user
MozReview-Commit-ID: 1x9zZukyygr
***
--HG--
extra : rebase_source : c31ad02cbbb106613914634b5192f856aad185b7
The Fennec CrashReporter class is also renamed to
CrashReporterActivity. When running in Fennec, the Activity will be used
which retains what we do today, prompting for comments, email, etc. When
used in standalone GeckoView, we report the crash without user
interaction if the appropriate GeckoRuntimeSetting was set. The app will
want to ask for user permission at least once in order to set this.
We do not collect the URL, email, or logcat with GeckoView crashes.
Logcat and URL would be nice to have, but it's not clear what the API
for those would look like, and they can be addressed in followup
patches.
MozReview-Commit-ID: C5ROsUKreRe
The Fennec CrashReporter class is also renamed to
CrashReporterActivity. When running in Fennec, the Activity will be used
which retains what we do today, prompting for comments, email, etc. When
used in standalone GeckoView, we report the crash without user
interaction if the appropriate GeckoRuntimeSetting was set. The app will
want to ask for user permission at least once in order to set this.
We do not collect the URL, email, or logcat with GeckoView crashes.
Logcat and URL would be nice to have, but it's not clear what the API
for those would look like, and they can be addressed in followup
patches.
MozReview-Commit-ID: C5ROsUKreRe
The current limit of at most one bfcache entry on Android dates back to when
Fennec was built for the Nokia N810, which had a whopping 128 MB of memory.
Since a few years have passed since then and mobile device technology has
evolved considerably, it should be safe now to allow a little more than that.
Since web sites sizes might have grown somewhat as well compared to the figure
of 4MB mentioned in CalcMaxTotalViweres(), though and to be absolutely on the
safe side, we still tweak the formula when building for Android, though.
If in the worst case even those assumptions turn out too generous, we will still
be protected by the fact that
- we temporarily disable the bfcache when the OS signals memory pressure, and
- our contentViewerTimeout is set to a lower value than on Desktop, so bfcache
entries will expire sooner
MozReview-Commit-ID: 1A6d0Q6Mdx0
--HG--
extra : rebase_source : 9cc1f7abb1aef82ffc4d7987773ae7cf35440884
Fix all Java warnings in the Android codebase except deprecation and
serial warnings, and warnings in third-party code.
There is one required change to exoplayer2 code under thirdparty,
because that code is included directly in the geckoview project, instead
of the thirdparty project. I think I'll just make a pull-request to
upstream the change, instead of separating exoplayer2 into a
gv-thirdparty project.
--HG--
extra : amend_source : 29419a24db9b956a7f3ee573a63f7a055ed90636
The Fennec CrashReporter class is also renamed to
CrashReporterActivity. When running in Fennec, the Activity will be used
which retains what we do today, prompting for comments, email, etc. When
used in standalone GeckoView, we report the crash without user
interaction if the appropriate GeckoRuntimeSetting was set. The app will
want to ask for user permission at least once in order to set this.
We do not collect the URL, email, or logcat with GeckoView crashes.
Logcat and URL would be nice to have, but it's not clear what the API
for those would look like, and they can be addressed in followup
patches.
MozReview-Commit-ID: C5ROsUKreRe
To allow users to opt-out from receiving LeanPlum messages we need a new setting added.
This are the Strings for the title and summary of that setting.
Localization notes also added as this Strings will ship before the feature.
Decided to suppress all UnusedResources Lint errors for android strings until the patch for #1454686 lands as using in-line suppression caused other errors.
Ran Lint locally, the build passed.
MozReview-Commit-ID: 9Kx567ruY3n
***
--HG--
extra : rebase_source : acb555719b4da9199364ca737ff140012dacb47c
This additionally introduces a new pref (toolkit.telemetry.isGeckoViewMode)
to discriminate, at runtime, between Fennec and GV in JavaScript code.
Moreover, this disables TelemetryController initialization from content
processes, which was left enabled.
MozReview-Commit-ID: 7VoDorxAhvD
--HG--
extra : rebase_source : b16a5c870c073f62175a5f9c2bf8db30032c55bd
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
This code was crashing in the framework; removing it should hopefully fix the
crash.
MozReview-Commit-ID: 2G3q4JrJ9tP
--HG--
extra : rebase_source : e9c1379b9dd3ebcb8ec2169165c629727344179d
At the moment the MediaControlService is structured such that it is started
shortly after Firefox has launched. Then, it registers a Tab event listener and
starts listening for various, mainly media-related tab events, in response to
which the playback notification is then shown or hidden as appropriate.
This setup has the drawback that the service itself has to remain running all
the time, even when we're not actually showing the notification, so Firefox now
keeps showing up as a "Running service" even when in background and not doing
anything interesting.
It is however relatively easily possible to move the tab event tracking into a
different class that won't require a service to stay alive, and set the Media-
ControlService's state (and at the same time start it if necessary) through a
set of special intent actions.
As the AudioFocusAgent is
a) alive for the whole lifetime of the application and
b) already interacting with the MediaControlService,
we designate it as the class responsible for this.
MozReview-Commit-ID: 1CzBpC1LTuZ
--HG--
extra : rebase_source : ef846bc1c52cb55fb1dfcdf05f2705f92358244e
Set process count to 1 because we only support one child process right
now.
MozReview-Commit-ID: HJAWvN4aqSX
--HG--
extra : rebase_source : 53e997b69b4b11fc3673a546ba0ad276e772d570
Set process count to 1 because we only support one child process right
now.
MozReview-Commit-ID: HJAWvN4aqSX
--HG--
extra : rebase_source : 8ade58427e8555f70a9349e6228b8aa7d1079781
Switch from the old XML-based AMO metadata API to the modern JSON based
API. This turned into something between a modest update and complete
rewrite. Most notably, external APIs became (mostly) promise-based. The
exception is getCachedAddonById() which XPIInstall.jsm requires a
synchronous callback from.
Also, hopefully we will be able to get rid of a bunch of this metadata
handling soon. If this code had a long life ahead of it, the unit tests
could use some more attention, but I mostly did the minimum here just to
keep them running for now with the expectation that we'll be able to get
rid of them within some small number of months.
MozReview-Commit-ID: 3DRaBdWGaiJ
--HG--
rename : services/sync/tests/unit/addon1-search.xml => services/sync/tests/unit/addon1-search.json
rename : services/sync/tests/unit/bootstrap1-search.xml => services/sync/tests/unit/bootstrap1-search.json
rename : services/sync/tests/unit/missing-sourceuri.xml => services/sync/tests/unit/missing-sourceuri.json
rename : services/sync/tests/unit/missing-xpi-search.xml => services/sync/tests/unit/missing-xpi-search.json
rename : services/sync/tests/unit/rewrite-search.xml => services/sync/tests/unit/rewrite-search.json
rename : services/sync/tests/unit/systemaddon-search.xml => services/sync/tests/unit/systemaddon-search.json
extra : rebase_source : f25d78b938768041c5c05b72a1f7ff3a7dee8275
In the next commit, we will send telemetry events in the sync ping.
The "event" JSON object doesn't have "uid"/"deviceID" fields (actually,
the "sync" objects shouldn't have them either!).
Let's do the right thing and send deviceID and UID as part of the top-level
"payload" object.
MozReview-Commit-ID: 3D3X3PcJAsW
--HG--
extra : rebase_source : 2ed71c7e6ce269cc43878f0e166dd9b149f3ccbc
Jan Henning
Andrei Lazar
Andreea Pavel
Eitan Isaacson
Michal Novotny
Petru Lingurar
Jim Chen
s37syed
Michael Kaply
Noemi Erli
James Willcox
Tiberius Oros
Andrew Gaul
Narcis Beleuzu
shindli
Andrew Swan
Alessio Placitelli
Brindusan Cristian
Vlad Baicu
Nicholas Nethercote
Margareta Eliza Balazs
Nick Alexander
Cameron McCormack
Kris Maglione
Ryan VanderMeulen
Gurzau Raul
Edouard Oger