Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
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
