1. 13 May, 2020 14 commits
    • 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
    • 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
  2. 12 May, 2020 18 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
    • 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
    • Jeff Boek's avatar
      For #6907 - Adds Media.State to concept-tabstray · f14626b5
      Jeff Boek authored
      - Maps MediaState from BrowserState when creating the Tabs list
      f14626b5
    • Jeff Boek's avatar
    • MozLando's avatar
      Merge #6880 · 99e1445b
      MozLando authored
      
      
      6880: Revert to previous tabs tray layout r=psymoon a=jonalmeida
      
      
      
      Co-authored-by: default avatarJonathan Almeida <jalmeida@mozilla.com>
      99e1445b
    • MozLando's avatar
      Merge #6951 · 23f1a7c6
      MozLando authored
      
      
      6951:  GeckoView update (nightly) (20200512-140959) r=psymoon a=MickeyMoz
      
      
      
      Co-authored-by: default avatarMickeyMoz <sebastian@mozilla.com>
      23f1a7c6
    • MickeyMoz's avatar
      Update GeckoView (nightly) (20200512-140959) · e64c3b29
      MickeyMoz authored
      e64c3b29
    • MozLando's avatar
      Merge #6950 · cb6e7a40
      MozLando authored
      
      
      6950:  Docs update (20200512-120756) [ci skip] r=Amejia481 a=MickeyMoz
      
      
      
      Co-authored-by: default avatarMickeyMoz <sebastian@mozilla.com>
      cb6e7a40
    • MozLando's avatar
      Merge #6666 · f8891561
      MozLando authored
      
      
      6666: For #2930 - Different BrowserToolbar behaviors depending on gestures r=pocmo a=Mugurell
      
      We'll now have a more in-depth understanding of user's gestures based on which
      we can trigger different BrowserToolbar behaviors depending on if the user is
      scrolling or zooming.
      
      The ConstraintLayout parent will still inform us about when the scroll begins
      and when the scroll ends but then actually incrementally updating the toolbar's
      translation will be done in response to GestureDetector callbacks.
      This also allows us to easily differentiate between horizontal and vertical
      scrolls and only react for the latter.
      
      If the user's gestures as inferred as zoom gestures (multi-finger scale or
      quick-scale) the toolbar should not be animated.
      This scenario is though affected by the fact that normally scroll gestures have
      a much higher sensitivity (a 1 pixel movement is enough for a gesture to be
      considered a scroll gesture) and so it is possible that even in the case of a
      desired zoom gesture the scroll callbacks will be fired first.
      When the gesture is identified as a zoom gesture we will immediately snap the
      toolbar up/down but there might be a minor visual glitch because of this.
      In an effort to reduce such races between scroll and zoom gestures I've lowered
      the sensitivity of the ScaleDetector, this having the other effect that
      multi-finger scrolls must now be more precise. Pinching while zooming will now
      more often mean a zoom gesture and not animate the toolbar.
      
      
      
      
      Co-authored-by: default avatarMugurell <Mugurell@users.noreply.github.com>
      f8891561
    • MickeyMoz's avatar
      Update docs (20200512-120756) · 7afe1d36
      MickeyMoz authored
      7afe1d36
    • Mugurell's avatar
      For #2930 - Different BrowserToolbar behaviors depending on gestures · ac7cb269
      Mugurell authored
      We'll now have a more in-depth understanding of user's gestures based on which
      we can trigger different BrowserToolbar behaviors depending on if the user is
      scrolling or zooming.
      
      The ConstraintLayout parent will still inform us about when the scroll begins
      and when the scroll ends but then actually incrementally updating the toolbar's
      translation will be done in response to GestureDetector callbacks.
      This also allows us to easily differentiate between horizontal and vertical
      scrolls and only react for the latter.
      
      If the user's gestures as inferred as zoom gestures (multi-finger scale or
      quick-scale) the toolbar should not be animated.
      This scenario is though affected by the fact that normally scroll gestures have
      a much higher sensitivity (a 1 pixel movement is enough for a gesture to be
      considered a scroll gesture) and so it is possible that even in the case of a
      desired zoom gesture the scroll callbacks will be fired first.
      When the gesture is identified as a zoom gesture we will immediately snap the
      toolbar up/down but there might be a minor visual glitch because of this.
      In an effort to reduce such races between scroll and zoom gestures I've lowered
      the sensitivity of the ScaleDetector, this having the other effect that
      multi-finger scrolls must now be more precise. Pinching while zooming will now
      more often mean a zoom gesture and not animate the toolbar.
      ac7cb269
    • MozLando's avatar
      Merge #6916 #6947 · 7b7310d1
      MozLando authored
      
      
      6916: Closes #6915: Add addon installation confirmation dialog r=Amejia481,csadilek a=psymoon
      
      
      
      6947: Closes #6791: Intermittent test failure in WebExtensionSupport r=psymoon a=csadilek
      
      Basically, we dispatch a tab browser action to test that our action handler works, but that in turn changes the tab state triggering our flow again (see registerHandlersForNewSession). We can simply verify and capture the handlers first, then trigger actions to test them.
      
      Co-authored-by: default avatarSimon Chae <chaesmn@gmail.com>
      Co-authored-by: default avatarChristian Sadilek <christian.sadilek@gmail.com>
      7b7310d1
  3. 11 May, 2020 8 commits