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
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
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
Needs to be explicitly declared in case we start targeting Android P.
It's unclear to what extent this is really required when *not* using Android's
network stack directly, but at least with Firefox, some things definitively use
it, e.g. favicons. As we're a browser, we need to allow access to arbitrary
pages, so just generally white-list it.
Differential Revision: https://phabricator.services.mozilla.com/D16408
--HG--
extra : moz-landing-system : lando
Dylan Roeh
James Willcox
Cosmin Sabou
Petru-Mugurel Lingurar
Ehsan Akhgari
Ryan Hunt
Nick Alexander
Andreea Pavel
Vlad Baicu
Margareta Eliza Balazs
alwu
Bogdan Tara
Eugen Sawin
Matt Brubeck
Eitan Isaacson
Alphan Chen
Julian Descottes
arthur.iakab
Sebastian Hengst
Sylvestre Ledru
Agi Sferro
Cameron McCormack
Dorel Luca
Daniel Varga
Gurzau Raul
Hiroyuki Ikezoe
Oana Pop Rus
Justin Wood
Jan Henning
Michael Kaply
Noemi Erli