6844: For #6757 - Adds firstContentfulPaint callback to SessionState r=pocmo a=ekager
Co-authored-by: ekager <ekager@mozilla.com>

6962: Close #6957: Allow nullable encoding param in push messages r=rocketsroger a=jonalmeida

We fall back to the "aes128gcm" encoding if the value is not provided.
Co-authored-by: Jonathan Almeida <jalmeida@mozilla.com>

We fall back to the "aes128gcm" encoding if the value is not provided.

6955: For #5028 - Add webAppManifest to ContentState r=jonalmeida a=NotWoods
Co-authored-by: Tiger Oakes <toakes@mozilla.com>

6972: Fixed #6914 CrashReporter: Log correct variable r=rocketsroger a=HaripriyaB
Co-authored-by: Haripriya Baskaran <b6haripriya@gmail.com>

6971: Issue #2985: Pass original article URL to JSDOMParser r=jonalmeida a=csadilek

Bug that happened in #2985 - passing the moz:// extensions (current page URL) instead of the original article URL to the new parser.

This causes relative links on a reader page to break as they link to moz://..../

 instead of the original page.
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>

6956: Close #6953: Report native fatal crash to Sentry as level FATAL r=pocmo a=rocketsroger
Co-authored-by: Roger Yang <royang@mozilla.com>

6875: Remove service-glean's hard-dependency on httpurlconnection r=Dexterp37 a=badboy

Remove service-glean's hard-dependency on httpurlconnection

We still test with it, so we keep it around.

*BREAKING CHANGE*:

Users will need to supply a configuration with a ping uploader to Glean
now.
A default lib-fetch-httpurlconnection implementation can be used like
this:

```kotlin
import mozilla.components.lib.fetch.httpurlconnection.HttpURLConnectionClient;
import mozilla.components.service.glean.config.Configuration;
import mozilla.components.service.glean.net.ConceptFetchHttpUploader;

val config = Configuration(httpClient = ConceptFetchHttpUploader(lazy { HttpURLConnectionClient() }))
Glean.initialize(context, true, config)
```

For Java this becomes:

```java
import mozilla.components.lib.fetch.httpurlconnection.HttpURLConnectionClient;
import mozilla.components.service.glean.config.Configuration;
import mozilla.components.service.glean.net.ConceptFetchHttpUploader;

ConceptFetchHttpUploader httpClient = ConceptFetchHttpUploader.fromClient(new HttpURLConnectionClient());
Configuration config = new Configuration(httpClient);
Glean.INSTANCE.initialize(context, true, config);
```

Fixes #6660 (at least partly)

I'm not familiar enough with service-experiments, so @travis79

 would need to take a look.

cc @pocmo for visibility.
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>

6961: Closes #6862: Migrate feature-accounts to browser-state r=grigoryk a=csadilek

For the FxA web channel, we don't need to connect to the content script if tabs are opened in the background (e.g. via long press->open in new tab) so I removed that code. The port is disconnected automatically when the window is "unloaded".

The actual change here is minimal, it's mostly the tests, which I refactored to reduce duplication.

Tested manually in Fenix as well.
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>

We still test with it, so we keep it around.

⚠️ **BREAKING CHANGE** ⚠

️

Users will need to supply a configuration with a ping uploader to Glean
now.
A default lib-fetch-httpurlconnection implementation can be used like
this:

```kotlin
import mozilla.components.lib.fetch.httpurlconnection.HttpURLConnectionClient;
import mozilla.components.service.glean.config.Configuration;
import mozilla.components.service.glean.net.ConceptFetchHttpUploader;

val config = Configuration(httpClient = ConceptFetchHttpUploader(lazy { HttpURLConnectionClient() }))
Glean.initialize(context, true, config)
```

For Java this becomes:

```java
import mozilla.components.lib.fetch.httpurlconnection.HttpURLConnectionClient;
import mozilla.components.service.glean.config.Configuration;
import mozilla.components.service.glean.net.ConceptFetchHttpUploader;

ConceptFetchHttpUploader httpClient = ConceptFetchHttpUploader.fromClient(new HttpURLConnectionClient());
Configuration config = new Configuration(httpClient);
Glean.INSTANCE.initialize(context, true, config);
```
Co-authored-by: Alessio Placitelli <alessio.placitelli@gmail.com>

6969:  GeckoView update (beta) (20200513-141004) r=Amejia481 a=MickeyMoz



6970:  GeckoView update (nightly) (20200513-141104) r=Amejia481 a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>

6946: Close #6903: Caught exception with no stack trace will be reported as UnexpectedlyMissingStacktrace r=pocmo a=rocketsroger
Co-authored-by: Roger Yang <royang@mozilla.com>

6968: README: Add link to Matrix explanation r=Amejia481 a=pocmo
Co-authored-by: Sebastian Kaspari <s.kaspari@gmail.com>

6966:  Docs update (20200513-121005) [ci skip] r=Amejia481 a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>

6964: Initialize accountManager on the main thread during migration r=pocmo a=grigoryk

Fenix bug for this - https://github.com/mozilla-mobile/fenix/issues/10432



This fixes fallout from #6395 in which
FennecMigrator changed to accept a Lazy-wrapped reference to the account manager.

This was done so that during regular (non-migrating) startup, a simple act of building a no-op
migrator will not cause account manager initialization.

However, during a migrating startup this creates a race to initialize account manager.
Two participants in this race are:
1) FenixApplication running expensive operations (such as storage init, account manager init)
after visual completeness. However, currently that just entails a 5 second delay from `onStart`.
2) FxA migration, which runs roughly at the mid-point of the migration.

Account manager currently can't be initialized on a background thread (or it will crash).
FxA migration runs on a background thread, so if (2) wins (that is, migrations before FxA migration take
less than 5 seconds), then migration will crash.

This patch adds an eager initialization right before we kick-off migrations but are still on the main thread,
iff an FxA migration will be executed.
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>

This fixes fallback from https://github.com/mozilla-mobile/android-components/pull/6395 in which
FennecMigrator changed to accept a Lazy-wrapped reference to the account manager.

This was done so that during regular (non-migrating) startup, a simple act of building a no-op
migrator will not cause account manager initialization.

However, during a migrating startup this creates a race to initialize account manager.
Two participants in this race are:
1) FenixApplication running expensive operations (such as storage init, account manager init)
after visual completeness. However, currently that just entails a 5 second delay from `onStart`.
2) FxA migration, which runs roughly at the mid-point of the migration.

Account manager currently can't be initialized on a background thread (or it will crash).
FxA migration runs on a background thread, so if (2) wins (that is, migrations before FxA migration take
less than 5 seconds), then migration will crash.

This patch adds an eager initialization right before we kick-off migrations but are still on the main thread,
iff an FxA migration will be executed.

6908: 🎲

 For #6907 - Dispatches tabsTray update when MediaState changes. r=jonalmeida,csadilek a=boek
Co-authored-by: Jeff Boek <jeff@jeffboek.com>

6909: Close #6842: Migrate to browser-state in BrowserThumbnails r=csadilek a=jonalmeida



6948: For #1159: Enable to download blob files in GeckoViewFetchClient r=Amejia481 a=kglazko
Co-authored-by: Jonathan Almeida <jalmeida@mozilla.com>
Co-authored-by: Kate Glazko <kglazko@Kates-MacBook-Pro.local>

6802: Closes #4992: Emit provider duration facts from BrowserAwesomeBar r=csadilek a=grigoryk

Some things to consider and trade-offs:

When recording durations of various providers into a glean metric, we have a bit of a hurdle.
One approach would be to encapsulate all of the awesomebar-related perf telemetry entirely within the
awesomebar a-c component. But, set of providers isn't entirely known to us at the a-c level.
We know what providers we have defined, but we don't know what providers applications will provide themselves.
Also, glean doesn't have a metric of type (string->timespan), which would allow us to work-around this.
So, we can't define ping/metrics in the a-c component. This means that they need to be defined elsewhere, while
the measurement happens within the component. An established pattern for that in the codebase is emitting "facts",
which is what this patch does.

We delegate to the consuming application to then actually do something with these facts - e.g. map providers
to concrete glean metric definitions.

Another consideration is if we should try to group timings related to a single query. That's hard to do reliably,
and will introduce additional complexity into what's otherwise a super simple setup. Source of that complexity
is that we actively try to cancel query jobs as user is typing; our providers could take an arbitrary time to resolve,
and so grouping becomes difficult. However, we care about improving how long each individual provider takes,
since that's a good proxy for "how responsive is this UI?". Simply recording each individual timing we see
should be enough for that.
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>

Some things to consider and trade-offs:

When recording durations of various providers into a glean metric, we have a bit of a hurdle.
One approach would be to encapsulate all of the awesomebar-related perf telemetry entirely within the
awesomebar a-c component. But, set of providers isn't entirely known to us at the a-c level.
We know what providers we have defined, but we don't know what providers applications will provide themselves.
Also, glean doesn't have a metric of type (string->timespan), which would allow us to work-around this.
So, we can't define ping/metrics in the a-c component. This means that they need to be defined elsewhere, while
the measurement happens within the component. An established pattern for that in the codebase is emitting "facts",
which is what this patch does.

We delegate to the consuming application to then actually do something with these facts - e.g. map providers
to concrete glean metric definitions.

Another consideration is if we should try to group timings related to a single query. That's hard to do reliably,
and will introduce additional complexity into what's otherwise a super simple setup. Source of that complexity
is that we actively try to cancel query jobs as user is typing; our providers could take an arbitrary time to resolve,
and so grouping becomes difficult. However, we care about improving how long each individual provider takes,
since that's a good proxy for "how responsive is this UI?". Simply recording each individual timing we see
should be enough for that.

6945: Fixes #5725 - Comment on Gecko manifest processing r=rocketsroger a=NotWoods
Co-authored-by: Tiger Oakes <contact@tigeroakes.com>