1. 21 Oct, 2019 1 commit
  2. 12 Oct, 2019 1 commit
    • Lina Cambridge's avatar
      Pass redirect source and target flags to history tracking delegates. · 15b873fe
      Lina Cambridge authored
      There's some confusion in `GeckoEngineSession` about redirect flags.
      The `VISIT_REDIRECT_SOURCE` and `VISIT_REDIRECT_SOURCE_PERMANENT` flags
      that we get from GeckoView's history delegate are for the redirect
      _source_, not the visit type. They indicate if the URL passed to
      `onVisited` is redirecting _to_ another URL, most likely because the
      server returned an HTTP 3xy status code with a `Location` header.
      Rust Places decides whether to mark the URL as hidden based on
      these flags.
      
      `VISIT_REDIRECT_{PERMANENT, TEMPORARY}`, however, indicate if the
      URL passed to `onVisited` is the _target_ of a redirect (in other
      words, the page that's _in_ the `Location` header). These get
      translated into `VisitType` flags, which Rust Places stores as the
      visit transition type. These two flags don't affect whether a URL
      is hidden.
      
      Note that, in a redirect chain, the middle links are both sources and
      targets. For example, in "mozilla.org" -> "www.mozilla.org" ->
      "www.mozilla.org/en-US", "www.mozilla.org" is both a redirect target
      (since "mozilla.org" redirected to it), and a source (it redirected
      to "www.mozilla.org/en-US").
      
      See mozilla-mobile/fenix#3526.
      15b873fe
  3. 27 Sep, 2019 1 commit
  4. 10 Jul, 2019 1 commit
    • Grisha Kruglov's avatar
      Move sync scope ownership into account manager; API simplification · 7afec7d4
      Grisha Kruglov authored
      I've started pulling on one little thread, and ended up with a few more changes than initially anticipated.
      
      Raison d'être for this PR - introducing access token caching for Sync.
      - Some background on the issue: Rust FirefoxAccount object maintains an in-memory cache of access tokens, keyed by 'scope'. During every sync, we "rehydrate" an instance of FirefoxAccount, starting with a fresh cache. We then obtain an access token from it to sync; this performs a network request (since the internal cache is empty), which is quite costly at scale for our services. This creates a situation when we may overwhelm our own servers with a large enough, actively syncing user base.
      - This PR adds a caching layer for sync authInfo objects. Sync workers no longer interact with the account directly, and instead look into the cache to obtain authentication info necessary for syncing. No more "talk to the FxA server before every sync".
      Account manager is responsible for keeping the cache up-to-date, and resetting it when necessary. Cache is currently updated: on startup (but only if access token has expired), on authentication, and when we recover from auth problems.
      
      And this is where the "thread pulling" begins! In order to "own" the access token for sync, account manager needs to be aware of the "sync scope".
      Before, we just relied on the application to specify that scope. Instead, I've changed account manager's constructor to take a SyncConfig object which allows consuming application to configure how sync should behave (enabled at all?, periodic syncing enabled? how often to sync? which stores should be synced?).
      Ownership of the "sync manager" moved down the stack, from the application layer into the account manager.
      
      Application is now expected to interact with sync only via AccountManager's `sync` method, which exposes an internal SyncManager instance (if sync is enabled).
      
      Above changes were a good reason to move support classes from feature-sync and into services-firefox-account. Note that since "sync" is part of our "storage" modules, this change doesn't mean that you need to take an extra native dependency on your classpath simply if you need to use FxA. Thanks to concept-sync, actual "Firefox Sync" machinery (within libplaces) is still fully decoupled from FxA. `feature-sync` has been removed entirely.
      
      Since we're churning the public API anyway, I took the chance to introduce a few more simplifications at the API layer:
      - 'SyncManager' interface was removed, since we're not expecting to have multiple implementations of it
      - 'Config' was renamed to 'ServerConfig'
      - 'DeviceTuple' was renamed to 'DeviceConfig'
      - account manager grew a new public API, 'setSyncConfig', which allows application to re-configure how it wants sync to behave
      - 'AuthInfo' was renamed to 'SyncAuthInfo', and a bunch of cleanup happened in that area
      - 'AccountObservable'@'onError' method was removed. The only error that could have been passed into it (unable to restore account) wasn't actionable by the application anyway, and none of the integrations did anything with that call
      
      Documentation of public APIs and classes was improved.
      7afec7d4
  5. 05 Jun, 2019 1 commit
  6. 03 Jun, 2019 1 commit
  7. 23 Apr, 2019 1 commit
  8. 28 Mar, 2019 1 commit
  9. 27 Mar, 2019 1 commit
  10. 22 Mar, 2019 1 commit
  11. 20 Mar, 2019 1 commit
  12. 15 Mar, 2019 1 commit
  13. 14 Mar, 2019 1 commit
  14. 13 Mar, 2019 3 commits
  15. 08 Feb, 2019 1 commit
    • Grisha Kruglov's avatar
      Perform browser-toolbar autocompletion off the UI thread · 28da6a5c
      Grisha Kruglov authored
      At this point in the stack, we're not in control over what our
      autocomplete providers are, what actions they'll do in order to
      field our queries, etc. For example, some providers may hit the disk
      and perform expensive DB queries internally. Some may even hit the
      network, in theory!
      
      In order to keep things perceptively speedy, let's run the actual work
      off the main thread. This patch sets up a new pool thread to process
      autocomplete requests. More than one thread is selected so that we maintain
      liveliness during quick user input. Background tasks are cancelled as new
      queries come in, and stale results are discarded.
      28da6a5c
  16. 01 Feb, 2019 1 commit
  17. 28 Jan, 2019 1 commit
  18. 30 Nov, 2018 3 commits
  19. 26 Nov, 2018 1 commit
  20. 20 Nov, 2018 1 commit
    • Grisha Kruglov's avatar
      Use `filesDir` as the parent folder for the places database file · 5a35bedd
      Grisha Kruglov authored
      Using getDatabasePath doesn't work without extra work on older API versions.
      That location doesn't exist, and it seems like we'd need to add a bit of code
      to check for its presence, create it, etc., before we can rely on that location.
      
      All of our other code which stores files just uses `filesDir`, and I don't see
      a reason not to put `places.sqlite` into that location as well. There isn't much
      value in that file living in a "databases" folder.
      5a35bedd
  21. 09 Nov, 2018 1 commit
  22. 07 Nov, 2018 1 commit
  23. 06 Nov, 2018 1 commit