There's a race condition here where we receive STATE_START before we've enabled GeckoViewProgressChild; this patch starts listening for web progress in onInit() rather than onEnable() so that we can guarantee progress tracking will work whenever a ProgressDelegate is set.
Add GeckoView Media API which provides a way to listen to HTMLMediaElement events in a GeckoSession and control the playback externally
Differential Revision: https://phabricator.services.mozilla.com/D9026
--HG--
extra : moz-landing-system : lando
about:addons on Android has some logic to ensure that only one theme can be
active at the same time.
At some point however, themes must have learned to take care of themselves in
that regard, which means that this code
a) has become unnecessary, and
b) with Webextension themes it can actually cause a harmful race condition:
Explicitly disabling the previously active theme implicitly enables the default
theme, so what happens is that depending on the size of the Webextension theme
to be enabled, the new theme can be enabled before the previous disable() call
completes. This leads to the new theme then immediately being disabled again as
the previous disable() call finally gets around to enabling the default theme.
The smaller the Webextension theme to be enabled and the faster it loads, the
more likely this is to happen.
We still need to manually fix up the disabled state of themes in the UI, though,
so that it shows the correct state without a reload. Therefore, we take the
opportunity to fix the problem that up until now, disabling a theme wouldn't
mark the default theme as enabled in the UI, unless you manually reloaded the
page afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D10732
--HG--
extra : source : 995ee600dc4eacac1f2d6c2409d83227c45f9d35
extra : histedit_source : 935f0d5c95bfc02acd296003fb65790cd9aa9a9d
We intercept the theme data just before sending it to the front-end in order to
fix it up as described in part 4.
There is one snag, though: When the theme data processed in Android's
LightweightThemeConsumer isn't fresh data received via lightweight-theme-
styling-update, but instead a theme retrieved via LWTManager
.currentThemeForDisplay, we risk passing already persisted theme data
to LWTPersister.persistImages().
When the LWTPersister encounters an image which already has a file:// URI, it
just skips it and doesn't call the success callback in that case, which means we
never execute the rest of the code to pass the data on to the Android front-end.
Even if it did, this would mean we'd be calling LWTPersister.getPersistedData()
twice: Once implicitly through asking for currentThemeForDisplay, and a second
time explicitly.
So instead, we're asking the LWTManager for currentThemeWithFallback, which
returns the original theme data, which we can then safely pass to
persistImages() and fix up ourselves through getPersistedData().
This introduces a different problem, though: If the same theme has previously
already been successfully persisted, we'd be unnecessarily persisting it again,
and even worse, we'd do that on each startup.
To avoid that, we make the LWTPersister store and then check the persisted
theme's ID and version.
If they have remained unchanged, we can short-circuit the call to persistImages
and immediately declare success.
Differential Revision: https://phabricator.services.mozilla.com/D10731
--HG--
extra : source : 679c830b57a2d59acbe978ea974cfac738443533
extra : histedit_source : 9b2e383a1900ccbe752c4737d1ce6780b9af63da
Bug 1344926 integrated static themes more closely into the existing infra-
structure for lightweight themes and also intended the static theme's image data
to be persisted to disk as well.
While the headerURL image file is in fact successfully copied out of the
extension archive into the profile, the persist progress listener being used
isn't equipped to properly handle this case and therefore the success callback
is never executed.
As a result
- the callback passed to _persistImages in the LWTManager isn't executed,
either, although because setting the fallbackThemeData passes in an empty
callback anyway, no one noticed.
- the persist operation never actually completes, so subsequent calls to
currentThemeForDisplay() always return the original moz-extension:// image URI
and never the persisted file from the profile folder.
For Android we definitively require a working callback in order to be able to
forward the fixed-up theme data once the image data has been persisted, so the
persistProgressListener's logic is modified accordingly.
Additionally, because as far as the LWTManager is concerned, WE static themes
are only fallback themes and a call to LWTManager.currentTheme will therefore
never return a WE static theme, the LWTPersister's logic to check whether the
theme, whose files have just been successfully persisted, is still the current
theme, needs to be modified.
Differential Revision: https://phabricator.services.mozilla.com/D10729
--HG--
extra : source : 91b2a9224846ef9cc81f1afc9fcfcd1db278644b
extra : histedit_source : d8a47bba3563cb8eb0faf94a7c1f28ba2925d80c
This tests that the moz-extension URI for the headerURL will be properly
rewritten into a file URI before being passed to the Android front-end.
The JS part of the test has been adapted for Robocop from toolkit/mozapps/
extensions/test/browser/browser_webapi_theme.js.
Likewise, the test extension is based on browser_theme.xpi from the same
directory, but modified to include a real image file that can actually be
persisted.
Differential Revision: https://phabricator.services.mozilla.com/D10727
--HG--
extra : source : 208f22eb4d94fdb2761c8cde881a1e5c2eade602
extra : histedit_source : 7aec3917ad22c7114d1ef801499f0eb7e598c019
The head.js used for Android chrome mochitests has a few useful functions for
waiting on events and observer service notifications, which I don't want to
duplicate yet another time.
While superficially similar, the JS environment of Robocop tests differs in
several ways from that of (chrome) Mochitests. Thankfully the only relevant
difference here is that setTimeout() isn't directly available from within a
Robocop JS test. As we're only using that to set a 0-length timeout, we can
easily replace it with an equivalent dispatchToMainThread() call.
Differential Revision: https://phabricator.services.mozilla.com/D10726
--HG--
extra : source : 541d630080dda9b79ad9576516484f7f8ea9b7ea
extra : histedit_source : 15ada66972b0997a68594247430a9b87d195d4b3
Most of robocop_head.js is based on xpcshell's head.js, but the log statements
should probably still use the new filename after all to reduce confusion.
Additionally, I've noticed that in do_report_unexpected_exception(),
Components.stack.caller can return null under some circumstances - to avoid
breaking error reporting as well as to make debugging easier, we should
therefore anticipate this possibility when getting caller_stack.filename.
Differential Revision: https://phabricator.services.mozilla.com/D10725
--HG--
extra : source : 5bfaa410d9385281b9b3ada226f1845a7d7426e7
extra : histedit_source : a2f482d4f9a3fad1c3d949800fd3bf31e907a254
Add GeckoView Media API which provides a way to listen to HTMLMediaElement events in a GeckoSession and control the playback externally
Differential Revision: https://phabricator.services.mozilla.com/D9026
--HG--
extra : moz-landing-system : lando
Although this two receivers are guarded by checks for if they were initialized
(and so registered) there are reports of crashes because of trying to unregister
them without them actually being registered.
The underlying issue will be investigated further in bug 1505685 but for the
moment wrapping the unregister operations in a try-catch saves the users from
a crash and because the unregister is done when the app is closed
(for the MmaDelegate receiver) or when the app finished playing media
(for the GeckoMediaControlAgent receiver) the user doesn't loose any
functionality going forward.
Differential Revision: https://phabricator.services.mozilla.com/D11177
--HG--
extra : moz-landing-system : lando
Add GeckoView Media API which provides a way to listen to HTMLMediaElement events in a GeckoSession and control the playback externally
Differential Revision: https://phabricator.services.mozilla.com/D9026
--HG--
extra : moz-landing-system : lando
For improved security, default to a null triggering principal for
GeckoView.loadUri calls, except when loading certain privileged schemes
such as "resource" and "file".
Differential Revision: https://phabricator.services.mozilla.com/D7785
This ensures that the vsync notifications don't race ahead of the touch
events, which can result in jank if the APZ sampling happens before the
touch events update the scroll position.
Differential Revision: https://phabricator.services.mozilla.com/D11042
--HG--
extra : moz-landing-system : lando
Not setting MOZILLA_OFFICIAL was an oversight, I believe, from when
Bug 1475573 landed the Android x86 debug fuzzing job. Nothing depends
on !MOZILLA_OFFICIAL and it's incongruent with the rest of the jobs
built in automation, which do set MOZILLA_OFFICIAL.
Differential Revision: https://phabricator.services.mozilla.com/D10931
--HG--
extra : moz-landing-system : lando
Defaults now to 'true', when caching is good enough I'll switch it off.
Generally, this would be used for apps/cases when full accessible tree
is needed like UIAutomator.
Depends on D9864
Differential Revision: https://phabricator.services.mozilla.com/D9865
--HG--
extra : moz-landing-system : lando
GeckoViewTab stubs out gBrowser on the root window for WebExtension compatibility.
LoginManagerParent also looks for gBrowser on windows that are handling username
and password form fills, and expects it to implement getBrowserForOuterWindowID.
This patch makes the stub implement getBrowserForOuterWindowID, which just returns
the lone GeckoViewTab browser.
Differential Revision: https://phabricator.services.mozilla.com/D10750
--HG--
extra : moz-landing-system : lando
The SafeBrowsing related testcases in NavigationDelegateTest.kt first tests loading bad URI and
then tests loading the URI again with |blockMalware| disabled.
When the testcase loads a bad URI with |blockMalware| disabled, the load succeed and the
HTTP response of the URI is stored in HTTP cache.
The next time we run the same test, the load is read from the cache without going through
url-classifier hence the load is not blocked.
Add query string to the URI to avoid bypassing url-classifier check.
Differential Revision: https://phabricator.services.mozilla.com/D10886
--HG--
extra : moz-landing-system : lando
`mExtensionPermissionsHelper` is initialized in BrowserApp's onCreate() and
nullified in it's onDestroy().
GeckoApp's onCreate() can finish after BrowserApp's onDestroy() because it uses
background initialization.
`mExtensionPermissionsHelper` will be checked for null before using it and
if null it's safe to ignore it's method's results as it only can be null if the
app was already closed.
Differential Revision: https://phabricator.services.mozilla.com/D10910
--HG--
extra : moz-landing-system : lando
Currently, we process replace-text events during `onTextChange` calls,
but we get confused if one `onTextChange` call corresponds to two or
more replace-text events. This patch makes us do minimal processing
during `onTextChange`, and perform the bulk of the processing during
each individual replace-text reply.
Differential Revision: https://phabricator.services.mozilla.com/D9851
Add a test for the text duplication bug caused by committing some text
and then immediately starting another composition.
Differential Revision: https://phabricator.services.mozilla.com/D9849
James Willcox
Cosmin Sabou
Razvan Maries
Marco Bonardo
Dylan Roeh
Agi Sferro
Eitan Isaacson
Johan Lorenzo
Imanol Fernandez
Jan Henning
Tooru Fujisawa
Gurzau Raul
Jim Chen
Matt Brubeck
Csoregi Natalia
Ehsan Akhgari
shindli
Petru Lingurar
Emily Toop
Daisuke Akatsuka
Mike Taylor
arthur.iakab
Kartikaya Gupta
Makoto Kato
Nick Alexander
Andreea Pavel
Mike Conley
dlee