On versions prior to Android N (24), initializing the WifiManager via Context#getSystemService can cause a memory leak if the context is not the application context.
Differential Revision: https://phabricator.services.mozilla.com/D14721
--HG--
extra : moz-landing-system : lando
This is because these persmissions are the responsibility of the embedding app to request,not GeckoView's.
Differential Revision: https://phabricator.services.mozilla.com/D14722
--HG--
extra : moz-landing-system : lando
The AOSP ExternalStorageProvider always creates document IDs of the form
"storage device ID" + ':' + "document path", where the storage device ID will
be "primary" for the primary emulated storage and the file system UUID for
everything else.
Assuming that OEMs won't customise this behaviour, the main problem that needs
to be handled is how to turn the file system UUID back into a file system path.
Differential Revision: https://phabricator.services.mozilla.com/D15259
--HG--
extra : moz-landing-system : lando
Because getOriginalFilePathFromUri() doesn't use framework methods newer than
Kitkat, instead of a generic @SuppressLint("NewAPI") it would be better to use
@TargetApi(19), so you still get warned if you start using framework methods
more recent than API19.
However because the isKitkat helper variable is only used in one place, in the
end we simply replace it with a direct Build.VERSION.SDK_INT check, so that we
don't have to use any special handling for the linter.
Differential Revision: https://phabricator.services.mozilla.com/D15258
--HG--
extra : moz-landing-system : lando
Instead, getOriginalFilePathFromUri() will simply *always* return null if it
cannot divine the original file path, and consequently resolveContentUri() will
then always fall back to the temp file method if getOriginalFilePathFromUri()
returns null.
Differential Revision: https://phabricator.services.mozilla.com/D15257
--HG--
extra : moz-landing-system : lando
All of the current usage can survive a timeout, and we'd rather
that than a deadlock. Future code that does want to risk a
deadlock can call `GeckoThread.waitOnGeckoForever` instead.
Differential Revision: https://phabricator.services.mozilla.com/D14560
--HG--
extra : moz-landing-system : lando
Audio/video related context menu entries are already doing this as far as I can
tell.
Differential Revision: https://phabricator.services.mozilla.com/D15382
--HG--
extra : moz-landing-system : lando
Desktop does this when copying link URLs and sharing is just effectively just
another form of copying.
For completeness, we also apply this when "viewing" the source of images (which
just displays the image itself anyway).
No special handling is required for other media elements (audio/video), because
looking at those in view-source mode does display the raw file contents and
thus none of the media-specific context menu entries will show up.
Differential Revision: https://phabricator.services.mozilla.com/D15381
--HG--
extra : moz-landing-system : lando
The `privateSession` key would normally allow persisting the Private Browsing
session across OOMs in Activity's Bundle.
We need to do that to avoid storing private, sensible data on disk like we do
with the normal browsing session.
In some cases `privateSession` would contain a lot of data which, along with
other possible concurrent transactions could overflow Binder's buffer which has
a limited fixed size, currently 1Mb.
To avoid this, we will drop `privateSession` from the Bundle if the resulting
size is greater than a _speculative_ size of 300KBs which would mean that in
the case of an OOM all Private Browsing state would be lost.
Bug 1515592 is filed to investigate for a better solution.
Differential Revision: https://phabricator.services.mozilla.com/D15067
--HG--
extra : moz-landing-system : lando
In Bug 1506601 we started specifying a version number which made the javadoc
jar artifact name change
from `geckoview-javadoc.jar` to `geckoview-<version>-javadoc.jar`
where `<version>` is the current GeckoView version. This is a good change but it
broke our javadoc publishing code which doesn't know about the version code in
`//taskcluster/ci/build/android-stuff.yml`.
To make that work we add a new task `copyJavadocJar${variantName}` which copies
the jar to the expected location.
Depends on D15128
Differential Revision: https://phabricator.services.mozilla.com/D15129
--HG--
extra : moz-landing-system : lando
This was fallout from Bug 1509573. That ticket pushed the Android APKs step
into the export tier, where it is required; but since most things in export are
only required for compilation, the target is not itself built by default, and
in particular, not during an artifact build. That's not right; this fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D15002
--HG--
extra : moz-landing-system : lando
This moves the CHANGELOG.md file to a /doc-files folder that gets picked up by
javadoc.
Our javadoc files are hosted on a github.io page which will render the markdown
file with the geckoview profile.
Depends on D13883
Differential Revision: https://phabricator.services.mozilla.com/D14786
--HG--
rename : mobile/android/geckoview/CHANGELOG.md => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/doc-files/CHANGELOG.md
extra : moz-landing-system : lando
This test formerly used a bootstrapped extension. Converting it to a
webextension is straightforward, except for the fact that webextensions
are started asynchronously, so the test has to wait for a message from
the addon instead of just assuming it is started synchronously during
distribution handling.
Differential Revision: https://phabricator.services.mozilla.com/D13635
--HG--
extra : moz-landing-system : lando
This splits the two stage-package invocations (which are rather slow)
between Fennec and GeckoView, hopefully speeding local GV development
up a little (in the IDE).
The stage-package invocations depend on |mach build faster|, because
the omnijar contents might need to be updated.
In addition, we feed the packaged libs (and asset libs) through.
Differential Revision: https://phabricator.services.mozilla.com/D12799
--HG--
extra : moz-landing-system : lando
This is just an awkward feature of the FasterMake build system:
without a direct consumer, GENERATED_FILES aren't handled. We
"consume" them into a dummy directory that isn't packaged. Sadly, the
FasterMake generic rule doesn't handle relative directories smoothly,
so we have to special case that too.
Differential Revision: https://phabricator.services.mozilla.com/D12796
--HG--
extra : moz-landing-system : lando
This uses |mach build mobile/android/base/...| rather than a custom
target, reducing Make magic and making it a little easier to reason
about the Gradle build. This is somewhat rearranging deckchairs, but
the more that gets out of Make and into moz.build, the simpler our
lives become.
The shared `onlyIf` Gradle guard will be used to make it very clear
when certain tasks are being skipped, as we move details about Gecko
binaries to depend on the Gradle task execution graph.
I also took the opportunity to improve the task logging.
Differential Revision: https://phabricator.services.mozilla.com/D12798
--HG--
extra : moz-landing-system : lando
This was always an accident of history: we forced export tier without
avoiding it in the libs tier.
Differential Revision: https://phabricator.services.mozilla.com/D14893
--HG--
extra : moz-landing-system : lando
Summary:
Add autofill hint test if using Android 8+.
Depends on D12881
Reviewers: droeh
Reviewed By: droeh
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12882
--HG--
extra : rebase_source : c4458b62d48434fe9d19f8ded04f2bc2666647ff
extra : histedit_source : 5ff01309b49965ff008e431059368ca0f05d56e6
Summary:
LastPass will fill password to all input elements which InputType is
TYPE_CALSS_TEXT and TYPE_TEXT_VARIATION_WEB_EDIT_TEXT and has no AutofillHint.
And it will fill username when InputType and AutofillHint is nothing in
<input type="text">.
Actually, current implementation of GeckoView sets InputType only for
<input type="text">, so LastPass fills password to all <input type="text">
So as workaround, we should set InputType and AutofillHint when input element
presumes username fields.
Depends on D12880
Reviewers: droeh
Reviewed By: droeh
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12881
--HG--
extra : rebase_source : b5ab3deadf0dd67bbdb1aa7e7656fe677c6670c4
This simplifies things all around, and gets rid of one more unnecessary
component registration.
--HG--
rename : toolkit/components/extensions/extension-process-script.js => toolkit/components/extensions/ExtensionProcessScript.jsm
extra : rebase_source : 7ceb6ada0730f8241bbd5ddbd889a320da22b1b1
This makes it so that apilints lints with "GV" codes are enforced and will fail
the build.
Depends on D13882
Differential Revision: https://phabricator.services.mozilla.com/D13883
--HG--
extra : moz-landing-system : lando
Agi Sferro
Emily Toop
Jan Henning
Hiroyuki Ikezoe
Michael Kaply
Ciure Andrei
Mark Banner
Bogdan Tara
Vlad Baicu
arthur.iakab
James Willcox
Cosmin Sabou
Eitan Isaacson
Petru Lingurar
Mike Taylor
Sebastian Hengst
Razvan Maries
Nick Alexander
Eugen Sawin
Margareta Eliza Balazs
Andrew Swan
Brindusan Cristian
Dustin J. Mitchell
Makoto Kato
Kris Maglione
Dennis Schubert