This class drives the autocomplete feature and previously only allowed for
adding a history or domains autocomplete provider.
With the new changes it will support adding and removing any autocomplete
provider individually or in bulk.
With more search providers querying the same history storage but only after
they try to cancel the in-progress queries it is possible for the cancel
requests to overlap and one search provider to cancel the queries of another.
To mitigate this a new method is available which will use the current input to
query the storage for as a way to drop new cancel requests for the same input.
WorkManager's Worker is created for periodically running storage maintenance operation on places database.
DB size limit is exposed from A-S that indicates the maximum DB size to aim for, in bytes. If the database
exceeds this size, a small number of visits will be pruned. This operation is done periodically by a periodic
work request that, optimally, will run once a day as long as the worker constraints are met.
A change in AS v93.6.0 made it so the underlying function
`LoginsStore.import_multiple` no longer returns the metrics as a JSON
string string. Instead it just encodes the unit struct. This was a
breaking change, but it's not listed properly in the CHANGELOG.
The fix is pretty simple: just assume that no logins failed to import.
- Introduces `CreditCardValidationDelegate` and a default implementation in `DefaultCreditCardValidationDelegate`
- Implements `onCreditCardSave` in `GeckoCreditCardsAddressesStorageDelegate`
- Refactors `CreditCard` from concept-engine to `CreditCardEntry` in concept-storage so that it can validated with the `CreditCardValidationDelegate`
* fixup the VisitObservation, HistoryVisitInfo APIs based on changes in a-s
* Uniffi top frecent site info (https://github.com/mozilla-mobile/android-components/issues/3)
* uses VisitTransition in HistoryVisitInfo (https://github.com/mozilla-mobile/android-components/issues/4)
* fixup the VisitObservation, HistoryVisitInfo APIs based on changes in a-s
* updated based on bookmarks being uniffied
* fix issues with how we are rethrowing places exceptions
* bump appservices version
* fix ktlint lexiographic and ununsed import errors
* updated fennec migration code
Co-authored-by: Tarik Eshaq <tarikeshaq@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This adds an abstract KeyManager class to our storage component, which
establishes a pattern of managing keys as used by our storage classes
that require encryption.
AutofillCrypto and LoginsCrypto become implementors of this basis class,
allowing them to explicitly share structure and some core functionality.
- remove KeyRecoveryHandler indirection, I don't think it was adding
any value
- AutofillCrypto and LoginsCrypto are now taking shape of a 'key
manager' type objects - they know how to get, validate and store keys,
as well as recover corresponding storage classes from key loss.
- AutofillCrypto now scrubs credit cards - removes encrypted CC numbers
and resets the sync engine - in case of key loss.
In feature-session we had some logic to filter out certain URIs. This
patch moves this logic into the storage layer, so that it has a broader
coverage - whenever we attempt to write some URL into the storage, we'll
now go through this filter.
Before, we'd only go through this filter for writes that were routed via
the HistoryDelegate.
After this change, direct writes (such as for metadata) are also
covered.
This shouldn't change all that much - the storage implementation is
likely to have rejected these URIs. Now, instead of letting it through
exceptions at us (which we catch and report via sentry), we simply don't
even call into the storage if we don't expect these calls to succeed.
This should reduce volume of "url without base" type of 'info' events we
see in Sentry.
Most of the time redirectSource isn't set, so this makes that field
optional, and switches away from a special enum (NOT_A_SOURCE) to just a
simple nullable.
* deleted module and related files along with occurrences
* lint fixes
* used PlacesHistoryStorage for storage and readmeFix
* test fixes 1
* Update feature-awesomebar tests to use mocked HistoryStorage
* Linter fixes for feature-awesomebar
* toolbar fix 1
* toolbar fix
* final code cleanup
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Copied the crypto code from autofill and adapted it for logins. At some
point it would be nice to combine the common parts here, but I figure
that can be a later issue.
Added code to migrate from a SQLCipher database to the new plaintext
ones. Choose the unimaginative "logins2.db" filename, feel free to pick
a different one.
Fixed some linter errors.
Updated `GeckoLoginStorageDelegate` to use the new `addOrUpdate()`
function.
Updated `LoginValidationDelegate` to use the new `findLoginToUpdate()`
function. Removed the Result.Error class. It was only returned from
`ensureValidAsync`, which we don't call anymore because `addOrUpdate()`
now does the validation. This means that we will now throw an error
instead of doing a no-op, hopefully that's okay. Removed the not
threadsafe warnings. I think this the login storage code should be
threadsafe in general because we use Arc/Mutex on the rust side
A key difference is that `shouldUpdateOrCreateAsync()` now inputs
`LoginEntry` rather than a `Login`. The old code had some confusing
bits with how it handled the `guid` field. For example, we could pass a
`Login` with a `guid` set to the `SaveLoginPrompt`, but depending on
what the final username was and how the dupe-checking turned out, we
could end up updating a login with a different `guid` or creating a new
login altogether. Using `LoginEntry` hopefully makes the story clearer.
There are a few edge cases where the behavior may change now that we no
longer use a GUID in the dupe-calculation. I'm pretty sure that it
shouldn't really change things from a user's point of view, but I need
to double-check the use cases here.
`Login.guid` is now non-nullable. `LoginEntry` should be used for login
data to be saved.
Replaced the field-level documentation in the `service:sync-logins`
README with a note to check out docs from `cconcept-storage`. The
README was just a copy of the documentation from `LoginsStorage.kt` and
it seems better refer people there rather than duplicate it.
Removed the unit tests. The main thing they were testing was
the `LoginValidationDelegate` dupe-handling but now that code is very
simple and and there are tests for `findLoginToUpdate()` in a-s
(components/logins/src/login.rs).
