Alex Catarineu authored Sep 05, 2020 and Matthew Finkel committed Dec 11, 2020

Bug 40030: Install HTTPS Everywhere and NoScript addons on startup

HTTPS Everywhere is installed as a builtin extension and NoScript as
a regular AMO addon. To avoid unnecessary I/O we only install NoScript
the first time, and rely on the browser addon updating mechanism for
keeping up with new versions. This is the same behaviour that was
implemented in the Fennec-based Tor Browser, where it was installed
as a "distribution addon", which also only occurred once.

Bug 40062: HTTPS Everywhere is not shown as installed

Also 40070: Consider storing the list of recommended addons

This implements our own AddonsProvider, which loads the list of
available addons from assets instead of fetching it from an
endpoint. In this list, we replace https-everywhere by
our https-everywhere-eff, so that the EFF one is shown as installed
in the addons list and the AMO one is not displayed.

Also, we hide the uninstall button for builtin addons.

Bug 40058: Hide option for disallowing addon in private mode

Bug 40001: Start Tor as part of the Fenix initialization

Bug 40028: Implement Tor Service controller

Bug 40028: Integrate Tor Controller into HomeFragment

Bug 40028: Implement Tor connect and logger screens

Bug 40028: Implement Tor Onboarding

Bug 40028: Implement new home screen

Bug 40028: Define bootstrapping events and Quick Start

Bug 40041: Implement Tor Network Settings

Bug 40041: Integrate Tor Network Settings

Bug 40020: Change applicationId

Bug 40020: Change app name

Bug 40020: Change deeplink scheme

Bug 40020: Change App icons

Bug 40073: Use correct branding on About page

Bug 40088: Use Tor Browser logo in migration screen

While StrictMode is not exclusively used for performance purposes, it's
primarily used for perf purposes so let's move it to the perf package
and code owner it.

By component groups, I mean I applied this to any class with the
class kdoc, "Component group for...".

There are a few instances of lazy we had to keep using the old API to
avoid having to update constructor arguments.

This is to clarify a misunderstanding I found in PR review.

In a followup PR, we need to add state to strictModeManager (the
number of suppressions). This is much simpler to do when this is defined
as a class rather than an object. However, when this is defined as a
class, `resetAfter` needs access to the strictModeManager. Instead of
passing it in as an argument, it made sense to move this function onto
the strictModeManager instead.

Since folks are used to calling:
```
StrictMode.ThreadPolicy.allowThreadDiskReads().resetAfter
```

We're going to have to add a lint check to prevent them from doing that.

I originally tried to create this PR leaving this as an object to keep
the change simple but it wasn't worth it - once the object started to
keep state, we'd need to manually reset the state between runs. Also,
the tests were already getting hacky with static mocking so it was
easier to address some of those issues this way too.

For #10342 - Part 3: Use the TopSitesUseCase in the BrowserToolbarController and SessionControlController

Use the provided `addPinnedSites` and `removeTopSites` use cases in `BrowserToolbarController` and `SessionControlController`.

lint check

renamed the intentReceived telemetry to appOpenedAllSource

added comments

removed unused code

moved lifecycle process to AppAllSourceStartTelemetry

moved tracking event out of init function

lint fix

moved appAllStartTelemetry to components

added bit more info about the metrics

added the  onReceivedIntent metric back

minor fix

change discriptions based on the comments frm MR

wrote test cases for AppAllSourceStartTelemetry.kt

lint fix

test case to mock application going background

post rebase:

post rebase:

fixed nit from comments

fixed nit from comments

fixed nit from comments

lint fix

lint fix

They were both in their packages by themselves, which feels unnecessary.
Unfortunately, a utils pkg is discouraged by kotlin but we don't have a
better place for them right now. Maybe an annotations/ pkg for the
latter?

* For #8017: add advanced autoplay controls

Make sure that we actually lazily initialize our storage layers.

With this patch applied, storage layers (history, logins, bookmarks) will be initialized when first
accessed. We will no longer block GeckoEngine init, for example, on waiting for the logins storage
to initialize (which needs to access the costly securePrefStorage).
Similarly, BackgroundServices init will no longer require initialized instances of the storage
components - references to their "lazy wrappers" will suffice.

In practice, this change changes when our storage layers are initialized in the following ways.
Currently, we will initialize everything on startup. This includes loading our megazord, as well.

With this change, init path depends on if the user is signed-into FxA or not.

If user is not an FxA user:
- on startup, none of the storage layers are initialized
- history storage will be initialized once, whenever:
  - first non-customTab page is loaded (access to the HistoryDelegate)
  - first interaction with the awesomebar
  - history UI is accessed
- bookmarks storage will be initialized once, whenever:
  - something is bookmarked, or we need to figure out if something's bookmarked
  - bookmarks UI is accessed
- logins storage will be initialized once, whenever:
  - first page is loaded with a login/password fields that can be autofilled
  - (or some other interaction by GV with the autofill/loginStorage delegates)
  - logins UI is accessed
- all of these storages will be initialized if the user logs into FxA and starts syncing data
  - except, if a storage is not chosen to be synced, it will not be initialized

If user is an FxA user:
- on startup, none of the storage layers are initialized
- sometime shortly after startup is complete, when a sync worker runs in the background, all storage
layers that are enabled to sync will be initialized.

This change also means that we delay loading the megazord until first access (as described above).

become available

The a-c side of this work is in https://github.com/mozilla-mobile/android-components/pull/6128

This switches Fenix to use `SyncableLoginsStorage`, which caches a connection internally
on first access, and doesn't expose any lock/unlock APIs at the public boundary.

Create an object that will execute its enqued tasks
when Fenix is visually complete.