Use MediaControlService's context when creating the notification in order to
prevent a NPE.
Differential Revision: https://phabricator.services.mozilla.com/D17391
--HG--
extra : moz-landing-system : lando
There can be a slight delay (in rapport with actually loading the page) until
the ContentBlockingEvent is received.
To account for this, we'll use an overly generous 500ms timeout before
actually checking if we have the right tracking status.
Differential Revision: https://phabricator.services.mozilla.com/D17344
--HG--
extra : moz-landing-system : lando
`Enter` will search for the next occurrence of the "Find" string.
`Shift+Enter` will search for the previous occurrence of the "Find" string.
For this, FindInPageBar will intercept all `onKey` events and
- on `KeyEvent.ACTION_DOWN` will consume `Shift+Enter` which would otherwise
insert a newline character in the search box
- on `KeyEvent.ACTION_UP` will do a new next/previous search depending on the
keys pressed.
Differential Revision: https://phabricator.services.mozilla.com/D17133
--HG--
extra : moz-landing-system : lando
The desktopMode property on Fennec's tab object is already being correctly being
preserved when (re)creating a tab [1], but we don't propagate its state to the
content window's desktop viewport mode setting.
[1] When restoring into a fresh tab, the session restore code passes the stored
desktopMode flag to addTab, whereas zombifying an existing tab destroys its
<browser>, but leaves the tab object's properties intact, so we merely need to
re-set the desktop viewport mode on the new <browser>'s content window.
Differential Revision: https://phabricator.services.mozilla.com/D17774
--HG--
extra : moz-landing-system : lando
We use foreground services, so this is necessary in order to be able to target
Android P.
The GeckoView example app needs it for the crash handling service.
Differential Revision: https://phabricator.services.mozilla.com/D16423
--HG--
extra : moz-landing-system : lando
android.test.* is no longer part of the main framework, so as per
https://developer.android.com/training/testing/set-up-project,
- we must no longer declare them as a *required* dependency in our manifests
- we must explicitly include a dependency on them in our build config
This will temporarily break running tests depending on android.test.* (i.e.
mainly Robocop) on devices using P or newer until we also start targeting P as
well.
Differential Revision: https://phabricator.services.mozilla.com/D16422
--HG--
extra : moz-landing-system : lando
Once we start compiling with API28, android.test.* is no longer part of the main
framework JAR and will be included from separate libraries instead.
Those additional JARs will then subsequently show up on the class path in
Gradle, too.
Because our SDKProcessor is currently set up to process only one JAR at a time
and because we don't actually need to generate bindings for those test classes,
we simply filter them out again.
We explicitly only filter the android.test.* JARs and use findAll so that if the
android classpath unexpectedly gains another member, we're alerted to that fact
and can consciously take a decision on whether to ignore it as well or not.
Differential Revision: https://phabricator.services.mozilla.com/D16421
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
VIEWPORT_MODE_DESKTOP *forces* the desktop mode viewport everywhere, whereas
VIEWPORT_MODE_MOBILE merely enables <meta> viewport support for pages that have
that tag defined, but still uses the desktop mode viewport for all other pages.
Differential Revision: https://phabricator.services.mozilla.com/D17159
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
After the changes from bug 1514340 the app is now informed about tracking with
Content:ContentBlockingEvent instead of Content:SecurityChange
Also initialized mLastTracking with unknown as that is the default value
when no tracking event has been received (eg: no tracking elements on the page)
Depends on D16822
Differential Revision: https://phabricator.services.mozilla.com/D16823
onSecurityChange from browser.js will not send information about tracking
anymore to Java (because it doesn't know about that anymore).
onContentBlocking from browser.js will be responsible for this from now on.
is called after onSecurityChange which will have created a SiteIdentity()
for that tab in Java
is informed only about tracking status which it caches to only send updates
downstream to Java. Will not propagate identical events one after the other.
will not fire for websites which do not contains any tracking elements
A Content:ContentBlockingEvent received in Java will update the tracking
property of SiteIdentity and finally update the UI with
ToolbarDisplayLayout#updateSiteIdentity().
Differential Revision: https://phabricator.services.mozilla.com/D16822
I'm taking an old ticket number just to close it. The files removed
no longer exist in the tree; the NSS option exists and probably
shouldn't -- but that's for another day, so let's just make it not
warn for now.
Depends on D15016
Differential Revision: https://phabricator.services.mozilla.com/D15017
--HG--
extra : moz-landing-system : lando
On debug builds whenever we would attempt to retrieve the value of localUid it
would be null because the LP debug id is never persisted.
Differential Revision: https://phabricator.services.mozilla.com/D16319
--HG--
extra : moz-landing-system : lando
We keep old cache code in the tree only because of offline cache. We no longer allow using old disk or memory cache. This patch removes all preferences manipulation from old cache code that isn't used by offline cache. It removes also some related code (e.g. everything smart size related, unused defines etc.), but the goal wasn't to remove all unused code from the old cache.
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
I quickly tested on Fennec with the whole stack and I am able to list workers, inspect workers etc...
Could not see any issue at first glance.
Differential Revision: https://phabricator.services.mozilla.com/D16175
--HG--
extra : moz-landing-system : lando
We can receive GeckoSession.onCompositorDetached() before
GeckoSession.onCompositorReady() has run, so guard against this
by ensuring the compositor is attached in onCompositorReady().
Differential Revision: https://phabricator.services.mozilla.com/D16983
--HG--
extra : moz-landing-system : lando
Summary:
Login data is to be removed only from "about:logins" where the users that use
Sync are also informed about the perils of doing so.
Depends on D16027
Reviewers: JanH, #geckoview-reviewers
Reviewed By: JanH
Subscribers: flod
Bug #: 1473470
Differential Revision: https://phabricator.services.mozilla.com/D16029
--HG--
extra : rebase_source : f7b9a885333e2b8bab310037aeced2e76812b8aa
extra : histedit_source : 85be5dca7ac79d4631d090cafc3f01994a4223b0
Summary:
The reason for this ticket was that it was not immediately obvious for
Sync users that deleting logins on this device may affect all logins stored in
user's Sync account. So it was possible that users could unintentionally loose
all their login data.
While we should still offer the option to remove login data, even to Sync users,
we will explicitly inform them that deleting logins can affect all their
synced logins.
Also refactored the code to minimize duplicated code.
Depends on D16026
Reviewers: JanH, #geckoview-reviewers
Reviewed By: JanH
Subscribers: reviewbot, flod
Bug #: 1473470
Differential Revision: https://phabricator.services.mozilla.com/D16027
--HG--
extra : rebase_source : a0e83ce91e7d217c6b46fa81472eb5f54c92420d
extra : histedit_source : b9d9435857c04a73d960275409fd65cf1725edcb
This eliminates one potential source of crashes from passing bad orientation
values to onOrientationChange.
Differential Revision: https://phabricator.services.mozilla.com/D16207
--HG--
extra : moz-landing-system : lando
The arguably most interesting bit of state of BrowserApp/GeckoApp, namely the
currently open tabs, are living partly in Gecko and partly in the Tabs
manager singleton, the lifetimes of both of which are tied to the lifetime of
the app process.
If the whole process has been killed, things are simple: Neither the Tabs
manager nor Gecko know anything about any tabs and we simply restore them
through the session store if enabled.
If GeckoApp is however being restored into an app process in which it had
already executed earlier on, meaning that we have some open tabs, it relies on
the savedInstanceState in order to correctly reconnect its GeckoView instance
with the correct previous GeckoSession.
We can however end up in a state where we don't have a savedInstanceState (e.g.
because the user swiped away the BrowserApp activity in the task switcher), but
the app process keeps running throughout (if another activity of ours is still
present in the task switcher, e.g. a custom tab, or else if a service is active,
then standard Android keeps the process running even if the user swipes away an
activity).
In that case, if GeckoApp is subsequently recreated, the Android UI sees all the
Android-side tabs in the Tabs manager, and Gecko in fact still has the Window
open that is containing all those tabs, but without the savedInstanceState
GeckoApp doesn't know anything about that Window and proceeds to open a fresh
session instead.
This means that all previous tabs will appear white and unresponsive, while
freshly opened tabs will load, but they won't be correctly saved in the session
store, their context menu isn't working, etc., because we're not really
expecting to handle multiple Gecko-side Windows.
To fix this, we disable automatic state-saving for GeckoApp's GeckoView instance
and instead do it manually, so we can keep another reference to the saved state
in GeckoApplication, and therefore are able to retrieve it from there for as
long as the app process keeps running.
Differential Revision: https://phabricator.services.mozilla.com/D16393
--HG--
extra : moz-landing-system : lando
