GeckoAppShell.runGecko really should be in GeckoThread because
GeckoThread already takes care of most of the preparation when running
Gecko. This patch merges runGecko into GeckoThread.run, but split the
argument-building code into its own method.
GeckoThread.LaunchState now covers the entire GeckoThread lifetime and
not just launch, so it's renamed to GeckoThread.State. More utility
methods are added to check for the current state.
JNIObject is the base class for any class that wish to use per-instance
native methods. It encapsulates the long native pointer that used to be
in NativeJSContainer.
Using my test page (https://people.mozilla.org/~mcomella/test/uri.html), I have
confirmed that the following schemes still work:
* intent
* android-app
* custom schemes registered w/ Android (i.e. "mcomella")
* tel
* mailto
Additionally, I downloaded a PDF and successfully opened it via both the
notifications tray and about:downloads.
This gives me confidence that all links should work.
There is some ambiguity about whether ScheduleComposite will necessarily
trigger a composite all the way to nsWindow::DrawWindowUnderlay. Android
robocop tests assume it will, because they rely on DrawWindowOverlay
being called so they can take a screenshot and make progress,
but this is a very fragile assumption. They also rely on the entire
window being painted, which is also a fragile assumption.
This patch improves the situation by explicitly invalidating the current
window area when Android Java code needs to trigger a composite. This avoids
regressions from future patches in this series which make composition bail
out when there is nothing invalid.
The resulting setup is still a bit fragile for my taste but I'm not sure
what the ideal solution would be.
This is more appropriate than our internal org.mozilla.gecko package name as it
provides the distinction across channels and has more public facing names than
gecko.
Before we only added this flag to the share intent used by the browser toolbar
menu.
Practically, this has the effect of having "Add to <current channel>" opening
the share overlay with *only* the device list wherever getShareIntent() is
used. Ideally, this method is used anywhere we use ACTION_SEND.
I've noticed this change makes both sharing from the long-press context menu
and about:reader to display *only* the device list.
