- 14 May, 2020 5 commits
-
-
MickeyMoz authored
-
MozLando authored
6844: For #6757 - Adds firstContentfulPaint callback to SessionState r=pocmo a=ekager Co-authored-by:
ekager <ekager@mozilla.com>
-
ekager authored
-
MozLando authored
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>
-
Jonathan Almeida authored
We fall back to the "aes128gcm" encoding if the value is not provided.
-
- 13 May, 2020 26 commits
-
-
MozLando authored
6955: For #5028 - Add webAppManifest to ContentState r=jonalmeida a=NotWoods Co-authored-by:
Tiger Oakes <toakes@mozilla.com>
-
Tiger Oakes authored
-
MozLando authored
6972: Fixed #6914 CrashReporter: Log correct variable r=rocketsroger a=HaripriyaB Co-authored-by:
Haripriya Baskaran <b6haripriya@gmail.com>
-
Haripriya Baskaran authored
-
MozLando authored
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>
-
Christian Sadilek authored
-
MozLando authored
6956: Close #6953: Report native fatal crash to Sentry as level FATAL r=pocmo a=rocketsroger Co-authored-by:
Roger Yang <royang@mozilla.com>
-
MozLando authored
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>
-
MozLando authored
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>
-
Jan-Erik Rediger authored
-
Jan-Erik Rediger authored
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>
-
MozLando authored
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>
-
Christian Sadilek authored
-
MickeyMoz authored
-
MickeyMoz authored
-
MozLando authored
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>
-
MozLando authored
6968: README: Add link to Matrix explanation r=Amejia481 a=pocmo Co-authored-by:
Sebastian Kaspari <s.kaspari@gmail.com>
-
Sebastian Kaspari authored
-
Sebastian Kaspari authored
-
MozLando authored
6966: Docs update (20200513-121005) [ci skip] r=Amejia481 a=MickeyMoz Co-authored-by:
MickeyMoz <sebastian@mozilla.com>
-
Sebastian Kaspari authored
-
MickeyMoz authored
-
MozLando authored
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>
-
Grisha Kruglov authored
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.
-
Grisha Kruglov authored
-
MozLando authored
6908:
🎲 For #6907 - Dispatches tabsTray update when MediaState changes. r=jonalmeida,csadilek a=boek Co-authored-by:Jeff Boek <jeff@jeffboek.com>
-
- 12 May, 2020 9 commits
-
-
MozLando authored
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>
-
Jonathan Almeida authored
-
MozLando authored
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>
-
Grisha Kruglov authored
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.
-
Kate Glazko authored
-
Roger Yang authored
-
Roger Yang authored
-
Jeff Boek authored
-
MozLando authored
6945: Fixes #5725 - Comment on Gecko manifest processing r=rocketsroger a=NotWoods Co-authored-by:
Tiger Oakes <contact@tigeroakes.com>
-