1. 12 May, 2020 14 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
    • 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
    • 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
  2. 11 May, 2020 12 commits
  3. 10 May, 2020 4 commits
  4. 09 May, 2020 3 commits
    • MozLando's avatar
      Merge #6929 · b82dd285
      MozLando authored
      
      
      6929:  GeckoView update (nightly) (20200509-140809) r=psymoon a=MickeyMoz
      
      
      
      Co-authored-by: default avatarMickeyMoz <sebastian@mozilla.com>
      b82dd285
    • MickeyMoz's avatar
      Update GeckoView (nightly) (20200509-140809) · 766dc26f
      MickeyMoz authored
      766dc26f
    • MozLando's avatar
      Merge #6889 · f1145fa7
      MozLando authored
      
      
      6889: Closes #6756: Addon data lost during migration r=grigoryk a=csadilek
      
      Grisha and I tested this and it's looking good so far:
      
      - Addon data (uBlock filters and settings) are still there post migration
      - Addon ID is stable now
      - In case migration leaves a broken prefs.js nothing bad happens and the file is just overridden with defaults
      
      Open questions:
      - ~Do we need to report more fine-grained success/failure results~ DONE
      - ~Do we need to be more tolerant parsing the file~ DONE
      
      Co-authored-by: default avatarChristian Sadilek <christian.sadilek@gmail.com>
      f1145fa7
  5. 08 May, 2020 7 commits