There may be cases where loopUntilIdle calls are nested. Allow these
calls by canceling the previous timeout when we set a new timeout. This
patch also adds some general optimizations to loopUntilIdle, so we don't
create a bunch of objects with every call.
MozReview-Commit-ID: 9glZu8ZTVZ5
--HG--
extra : rebase_source : 6d01c0f5cc14b54b369e3d600f136e56ba96bfc9
The session returned through the onNewSession response is opened
internally by GV. GeckoSessionTestRule should trap that and wait on the
newly opened session, just like we do for any other session, so that
this internal open operation is transparent to the test.
MozReview-Commit-ID: HOvEsSVZufS
--HG--
extra : rebase_source : 46ca4d3d0d8eb08d8092b91840c4aee94ee6e486
Update content modules to use the "GeckoView:UpdateModuleState" message
instead of "GeckoView:Register"/"GeckoView:Unregister", similar to what
we already do for parent modules. Also only call onSettingsUpdate in
content module when the module is enabled, similar to what we already do
for parent modules.
MozReview-Commit-ID: C30W9iEd7Rz
--HG--
extra : rebase_source : 0ff689e9e03655df0d7206ad0bb49b751bd0119d
During session initialization, pass in the enabled state of all modules
through the init-data, and use that to enable modules if necessary. This
avoids a race condition where we enable modules too late on startup due
to event queuing.
MozReview-Commit-ID: I0rvq6UoOVh
--HG--
extra : rebase_source : df5d469d0b4a0a402e4b75cd74e52559f395e6bc
There's a race in EventDispatcher, where the ready state can change
during a dispatch. In that case, we can end up neither dispatching an
event nor queuing it, which effectively drops the event.
MozReview-Commit-ID: GvjSUzjBrsT
--HG--
extra : rebase_source : bed4e368b5ab1cc7653daea57f20ab25dfa1f125
From the main thread, we need to get the result of evaluateJS()
asynchronously, because the JS code may depend on delegate callbacks on
the main thread, which cannot happen if evaluateJS() is synchronous. The
simplest example is an alert() JS call that depends on the prompt
delegate callback.
This patch makes RDPConnection read input packets on a background
thread, and the main thread can either poll for input synchronously, or
rely on asynchronously posted messages. Actor is extended to allow for
multiple pending inputs, and it now exposes a nicer ReplyParser
interface for turning reply packets into result objects.
MozReview-Commit-ID: I0eKeOzf2Jy
--HG--
extra : rebase_source : d12ad5f4c876f51e944ff202289cdc7e29b5bf99
Add GeckoSessionTestRule.setPrefsUntilTestEnd and
GeckoSessionTestRule.setPrefsDuringNextWait so tests can easily set
prefs to get specific behavior.
MozReview-Commit-ID: FquaonwfF5v
--HG--
extra : rebase_source : 8a9a543a89f0976ef8476630cd9192518c4a9cfc
Add GeckoSessionTestRule.evaluateChromeJS for JS code that requires
chrome privileges, such as setting prefs.
MozReview-Commit-ID: G7NUKukWTT8
--HG--
extra : rebase_source : c0d4684ba5a9d4735e30b49f584e8e0222210c87
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
Right now we pass a bundle to GeckoLoader.setupGeckoEnvironment() with
magic keys representing the environment variables. Instead of this,
simply pass a list of Strings.
MozReview-Commit-ID: D6mSTnYpnGu
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
Right now we pass a bundle to GeckoLoader.setupGeckoEnvironment() with
magic keys representing the environment variables. Instead of this,
simply pass a list of Strings.
MozReview-Commit-ID: D6mSTnYpnGu
Since bug 1104622, that pref has in fact been unused, so us setting that value
to 0 on memory pressure didn't really achieve anything.
Instead, the SurfaceCache already does its own memory management and discards
image surfaces when receiving a memory-pressure notification.
MozReview-Commit-ID: 4aqvclgvLhX
--HG--
extra : rebase_source : c8e8970ec748ea754545e0f563d86615e220f647
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
Instead of the helper methods in GeckoBundle, add SDK JNI calls for the
boxing/unboxing operations, and use those calls directly. Moreover, for
unboxing Boolean/Double/Integer, use their internal "value" field value
directly if possible, to avoid making a JNI method call.
MozReview-Commit-ID: Azvov1gCeje
--HG--
extra : rebase_source : 34cd4a821d2b47e48957f241bbf165439635be59
If our window closes while we're spinning the event loop, stop spinning
as soon as possible so we can continue with cleaning up the window.
MozReview-Commit-ID: ByS0c6R0cM8
--HG--
extra : rebase_source : 6d32f1e8c6d6119eaaacb6a3ef5d9319c884e642
Experimentally try using a String literal in case the NullPointerException at
that line is caused by some weird class initialisation issue.
MozReview-Commit-ID: 1BexpntTBEJ
--HG--
extra : rebase_source : ea71f390ce0d683cd635aae52825871562b78feb
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
The problem is we rely on some events / frame scripts for session calls
that should still work even if we don't have a delegate assigned, so we
should always register these events / frame scripts.
MozReview-Commit-ID: 6TvvMhc7qOf
--HG--
extra : rebase_source : 30d939a4e39488ca039709ec5b59532506bd18ed
Make GeckoSessionHandler and GeckoSessionSettings use the updated
"GeckoView:EnableModule" and "GeckoView:UpdateSettings" events.
Also, send events for updating settings only while the session is open.
Don't send events while the session is closed, because when opening the
session, we will send settings in one batch in the init-data.
MozReview-Commit-ID: Kytx8Ak4A5p
--HG--
extra : rebase_source : add58cb9cefcfaab7d109c492bb4406ee38f9e28
Let ModuleManager keep the current settings and enabled states for
modules. It initializes settings and module states from the window
init-data, and then listens to changes in them.
Having ModuleManager manage these states helps keeping things
consistent, and makes it possible for future optimizations like
delay-loading modules.
MozReview-Commit-ID: AM6lAxnUGhd
--HG--
extra : rebase_source : 2751990bec6054cc36104957690d8fce6d3da399
Instead of passing a live settings object to the native Window, pass a
static initialization data bundle to the Window. The bundle contains
settings at the time of creation. All changes to settings after creation
are updated through events, rather than the live object.
Using a live object between Gecko and UI threads has some drawbacks,
including the need to lock the object, and the fact it won't work with
remote runtimes across processes.
MozReview-Commit-ID: 1DngLfJ0Fnc
--HG--
extra : rebase_source : 05c0ba76ce7f45a02557cc1a30e399682dccd5a7
On Android 7.0.0, the OS would start the StumblerService and without having given fennec the location permission the intent and scan enabled checks would've been skipped - which ensure that the Stumbler Service does not run in unadequate scenarios.
MozReview-Commit-ID: AGU67ytE4ff
--HG--
extra : rebase_source : 7d1285e75ffa233e4888e65505081bca2200b34e
