This patch makes GLContextProviderEGL create EGL surfaces through
nsWindow/nsIWidget on Android. nsWindow then calls GLController in Java
to actually create the surface.
GLController instances are associated with a particular nsWindow, rather
than a particular View. Therefore, we need to let GeckoView manage
GLController instances, as part of GeckoView's handling of saving and
restoring states.
One nsWindow will have one corresponding GLController, and using native
GLController methods instead of GeckoEvents lets us control the
compositor for each nsWindow separately.
GeckoViewSupport better reflects the purpose of the class and will match
the GLControllerSupport class that another patch is adding. This patch
also changes the way GeckoViewSupport is constructed in order to be more
encapsulating.
Right now, code that queues native calls through GeckoThread can
encounter a race condition, after the GeckoThread state changes but
before we flush the existing queued calls. In that case, the new call
will be made before existing queued calls are made, and the order of
calls is disrupted. This patch moves flushing existing calls to before
the state changes, to avoid this race condition.
Right now LayerView depends on geckoConnected being called by GeckoApp
or GeckoView during its initialization. However, we can get rid of it
and let LayerView handle the task itself. As part of this change, screen
depth overriding is moved to native code in nsAppShell.
This patch adds auto-generated bindings for LayerRenderer.Frame, and
uses the new bindings in nsWindow, in place of the old manual bindings
in AndroidJavaWrappers.
We already take care of this in AdjustConstants where we return
StubAdjustHelper if MOZ_INSTALL_TRACKING is not defined.
However, the one downside to this is that we touch SharedPreferences on the
main thread in onCreate even if Adjust is disabled. However, our release and
beta users already have this problem (since Adjust is enabled) so who cares if
our Nightly and Aurora users also have this problem.
--HG--
extra : commitid : 23AwrEm4oaZ
extra : rebase_source : d1b1aa228878d18ef01091b0c5b693972237e3c8
This build configuration doesn't appear to run in automation which is why it
wasn't caught.
--HG--
extra : commitid : 5qshNdMfM61
extra : rebase_source : 59361d1d143da918cc498cf1725ea9a2604fbde5
This patch will prevent Firefox from downloading OMA download descriptors on
its own. Instead it will prompt to complete the action with an external app
if available. An error will be shown if no external app can handle the download.
--HG--
extra : commitid : KkCCwQrWwUv
extra : rebase_source : 2650328814b9ec5bba64d802b863d0ff7b3cacfc
CLOSED TREE
Backed out changeset 1cf6f364d319 (bug 1220309)
Backed out changeset f774157cf5f4 (bug 1220309)
Backed out changeset bd4581fe6c9d (bug 1220309)
It made sense to me to have this code inside the AdjustHelper so I moved the
existing opt out code inside the AdjustHelper as well.
--HG--
extra : commitid : Bc0yHD6v3UW
extra : rebase_source : f48a555ef71b658deb978808594faa06195ceca9
I added these to BrowserApp to match the use of Adjust.onCreate in BrowserApp.
These sessions don't perfectly match the FHR sessions they replace which get
called in:
GeckoApp.onPause (session end)
BrowserHealthRecorder.onEnvironmentTransition (session end)
BrowserHealthRecorder.checkForOrphanSessions (session start)
- From BHR.initializeStorage <- BHR.handleMessage. I didn't figure out
where this message comes from but given "initializeStorage", I assume
this comes from a startup routine of GeckoApp.
However, the Adjust docs are explicit about adding these values to
onPause/onResume and presumably written under the assumption that those methods
are called in the appropriate places.
The docs also mention these calls should occur in all Activities but I followed
FHR where only the main Activity is logged - I don't predict any negative side
effects from this change.
--HG--
extra : commitid : GxcpliEbSHh
extra : rebase_source : 817fbc5d422e1a3227054fd6276e86d8d441396a
AppCompat capitalizes all text in `Button`s so we have to override
that behavior to maintain the same UI. Ideally, we do this through
`android:buttonStyle` but the place I found the issue doesn't inherit
from that style so we can't and we change the style directly.
There may be issues with other `Button`s, but this is the only one I found.
--HG--
extra : commitid : JWDZBWuhsYy
extra : rebase_source : 534d09ceca6d15bfd1ad49772ee0f3bfad4751c1
