1. 14 May, 2020 5 commits
  2. 13 May, 2020 26 commits
    • MozLando's avatar
      Merge #6955 · df2b7c35
      MozLando authored
      
      
      6955: For #5028 - Add webAppManifest to ContentState r=jonalmeida a=NotWoods
      Co-authored-by: default avatarTiger Oakes <toakes@mozilla.com>
      df2b7c35
    • Tiger Oakes's avatar
      99ba7542
    • MozLando's avatar
      Merge #6972 · e13f1623
      MozLando authored
      
      
      6972: Fixed #6914 CrashReporter: Log correct variable r=rocketsroger a=HaripriyaB
      Co-authored-by: default avatarHaripriya Baskaran <b6haripriya@gmail.com>
      e13f1623
    • Haripriya Baskaran's avatar
      f61a830a
    • MozLando's avatar
      Merge #6971 · ac4eaaa1
      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: default avatarChristian Sadilek <christian.sadilek@gmail.com>
      ac4eaaa1
    • Christian Sadilek's avatar
    • MozLando's avatar
      Merge #6956 · 86f121a8
      MozLando authored
      
      
      6956: Close #6953: Report native fatal crash to Sentry as level FATAL r=pocmo a=rocketsroger
      Co-authored-by: default avatarRoger Yang <royang@mozilla.com>
      86f121a8
    • MozLando's avatar
      Merge #6875 · 6719e010
      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: default avatarJan-Erik Rediger <janerik@fnordig.de>
      6719e010
    • MozLando's avatar
      Merge #6961 · 956bc5f9
      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: default avatarChristian Sadilek <christian.sadilek@gmail.com>
      956bc5f9
    • Jan-Erik Rediger's avatar
    • Jan-Erik Rediger's avatar
      Remove service-glean's hard-dependency on httpurlconnection · a660d340
      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: default avatarAlessio Placitelli <alessio.placitelli@gmail.com>
      a660d340
    • MozLando's avatar
      Merge #6969 #6970 · b37e56ca
      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: default avatarMickeyMoz <sebastian@mozilla.com>
      b37e56ca
    • Christian Sadilek's avatar
    • MickeyMoz's avatar
      Update GeckoView (nightly) (20200513-141104) · 3b24876b
      MickeyMoz authored
      3b24876b
    • MickeyMoz's avatar
      Update GeckoView (beta) (20200513-141004) · 0a151114
      MickeyMoz authored
      0a151114
    • MozLando's avatar
      Merge #6946 · c29ab1d9
      MozLando authored
      
      
      6946: Close #6903: Caught exception with no stack trace will be reported as UnexpectedlyMissingStacktrace r=pocmo a=rocketsroger
      Co-authored-by: default avatarRoger Yang <royang@mozilla.com>
      c29ab1d9
    • MozLando's avatar
      Merge #6968 · 535941c2
      MozLando authored
      
      
      6968: README: Add link to Matrix explanation r=Amejia481 a=pocmo
      Co-authored-by: default avatarSebastian Kaspari <s.kaspari@gmail.com>
      535941c2
    • Sebastian Kaspari's avatar
      Update changelog for 41.0.0 release. · 35ce172c
      Sebastian Kaspari authored
      35ce172c
    • Sebastian Kaspari's avatar
      Set version to 42.0.0. · 67b48bf6
      Sebastian Kaspari authored
      67b48bf6
    • MozLando's avatar
      Merge #6966 · 075c26c3
      MozLando authored
      
      
      6966:  Docs update (20200513-121005) [ci skip] r=Amejia481 a=MickeyMoz
      Co-authored-by: default avatarMickeyMoz <sebastian@mozilla.com>
      075c26c3
    • Sebastian Kaspari's avatar
      README: Add link to Matrix explanation · 7fd2a924
      Sebastian Kaspari authored
      7fd2a924
    • MickeyMoz's avatar
      Update docs (20200513-121005) · b8d5de30
      MickeyMoz authored
      b8d5de30
    • MozLando's avatar
      Merge #6964 · 50fb753a
      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: default avatarGrisha Kruglov <gkruglov@mozilla.com>
      50fb753a
    • Grisha Kruglov's avatar
      Initialize accountManager on the main thread during migration · 09b55546
      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.
      09b55546
    • Grisha Kruglov's avatar
      Pre: metrics doc change · 2f1be9b4
      Grisha Kruglov authored
      2f1be9b4
    • MozLando's avatar
      Merge #6908 · 11940fba
      MozLando authored
      6908: 🎲
      
       For #6907 - Dispatches tabsTray update when MediaState changes. r=jonalmeida,csadilek a=boek
      Co-authored-by: default avatarJeff Boek <jeff@jeffboek.com>
      11940fba
  3. 12 May, 2020 9 commits
    • MozLando's avatar
      Merge #6909 #6948 · b8a37bae
      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: default avatarJonathan Almeida <jalmeida@mozilla.com>
      Co-authored-by: default avatarKate Glazko <kglazko@Kates-MacBook-Pro.local>
      b8a37bae
    • Jonathan Almeida's avatar
    • MozLando's avatar
      Merge #6802 · 6f9b7001
      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: default avatarGrisha Kruglov <gkruglov@mozilla.com>
      6f9b7001
    • Grisha Kruglov's avatar
      Closes #4992: Emit provider duration facts from BrowserAwesomeBar · d63dc810
      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.
      d63dc810
    • Kate Glazko's avatar
    • Roger Yang's avatar
    • Roger Yang's avatar
    • Jeff Boek's avatar
      For #6907 - Adds test for TabSessionState · 3dc55a7f
      Jeff Boek authored
      3dc55a7f
    • MozLando's avatar
      Merge #6945 · ba0d00e9
      MozLando authored
      
      
      6945: Fixes #5725 - Comment on Gecko manifest processing r=rocketsroger a=NotWoods
      Co-authored-by: default avatarTiger Oakes <contact@tigeroakes.com>
      ba0d00e9