The tracker base class currently does two things: bump the score in
response to observer notifications, and store a list of changed IDs.
The bookmarks, form autofill, and now bridged trackers need to hack
around this to opt out of persistence, since they handle change
tracking in the storage layer.
This commit keeps the score logic in `Tracker`, but moves all the
persistence code into an intermediate `LegacyTracker` class, and
changes all engines that need persistence to inherit from it.
`ignoreAll` is more interesting. We want new-style stores to emit
observer notifications with change sources, so that the tracker knows
to ignore changes made by Sync. Ignoring all observer notifications
during a sync is a blunter version of this. But, not every new store
supports change sources, so we reimplement `ignoreAll` manually for
ones that don't.
Differential Revision: https://phabricator.services.mozilla.com/D74374
To use a single transaction for `importJSONDump`, this commit:
- changes IDBHelpers' `executeIDB` method to take either a string or array
pointing to `objectStore`s that the caller wants to use.
- uses that from RemoteSettingsWorker to start a single transaction using both
the `records` and the `timestamps` store
- updates `bulkOperationHelper` to take an optional `completion` callback, in
addition to the rejection callback, to be called when all the bulk
operations are complete
- uses that optional argument from RemoteSettingsWorker's `importDumpIDB`
(the actual implementation of IDB access from `importJSONDump`) to first
bulk-import the actual records, and then update the timestamp stored for
that remote settings collection.
Then to abort that single transaction, this commit:
- stores pending transactions in a set, similar to what Database.jsm already
does, and removes items from that set when the `promise` from `executeIDB`
either resolves or rejects.
- adds a `prepareShutdown` action on the RemoteSettingsWorker's `Agent` class,
to be called by the jsm side of the worker manager when shutdown happens.
When called, it iterates over the pending transactions and aborts all of
them.
This also sets a `gShutdown` flag.
- ensures that where code `await`s in the middle of an operation, it stops
(throws) immediately if `gShutdown` has been set.
- adds a test to test_shutdown_handling.js to verify that this mechanism now
stops pending import tasks in the worker.
Finally, as a driveby, fixes an oversight in test_remote_settings_worker.js
where the second `.get()` call wasn't actually testing whether the
`importJSONDump` call in the worker had succeeded, because if the collection
was empty it would do the import itself, which I realized when I used similar
code in the shutdown test...
Differential Revision: https://phabricator.services.mozilla.com/D74315
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
This commit adds syncing support to the `StorageSyncArea` class, via
the Golden Gate library.
It also changes the `BridgedEngine` trait: `initialize` and `finalize`
haven't been useful in practice, since that's managed by the storage
service, and the `LazyStore` takes care of setting up the storage
connection on first use. But, what we do need is a way to signal a
sync is starting, so that the engine can set up temp tables. That's
handled by the new `sync_started`.
Finally, this commit changes `BridgedEngine::set_uploaded` to take a
`sync15_traits::Guid` instead of a `String`.
Differential Revision: https://phabricator.services.mozilla.com/D73415
This commit splits `CryptoWrapper` into a base `RawCryptoWrapper`
class, which only handles encryption and decryption without
parsing the cleartext's contents, and the existing `CryptoWrapper`
class, which works like before.
Our bridged engine subclasses `RawCryptoWrapper`, and
implements some methods to convert records to and from envelopes.
Envelopes are a concept we introduced in `sync15_traits` to pass
along metadata from the BSO wrapper (like the modified time from the
server, and ID, to ensure they match) in addition to the cleartext.
This lets us reuse `sync15_traits::Payload` to parse record payloads
in Rust, and avoids parsing the cleartext in JS, only to stringify it
again when we pass it to the bridged Rust engine.
Differential Revision: https://phabricator.services.mozilla.com/D73581
This commit adds a `mozIInterruptible` implementation to
`StorageSyncArea`, and changes `LazyStore` to get an a-s interrupt
handle and interrupt pending operations.
Differential Revision: https://phabricator.services.mozilla.com/D73414
This commit removes the `nsICancelable` return values from all
`mozIBridgedSyncEngine` methods, and replaces them with a
`mozIInterruptible` interface that can be implemented by store
classes that support interrupting.
The `nsICancelable` pattern was intended to make each operation
interruptible, without affecting the others. But we can't guarantee
that with SQLite, because it only has a way to interrupt all
running statements on a connection, not specific ones. Further,
this pattern doesn't match what we currently do in a-s, where we
create an internal "interrupt scope" for each operation, and hand
out an "interrupt handle" for interrupting all in-progress
operations.
Storage classes like `StorageSyncArea` can opt in to interruption
by implementing `mozIInterruptible`. It's a separate interface to
protect against accidental misuse: because it interrupts all
statements on the connection, it might lose writes if the current
operation is a `set`, for example. But it's useful for testing and
debugging, so we still expose it.
This commit also changes Golden Gate ferries to hold weak references to
the `BridgedEngine`, so that they don't block teardown.
Differential Revision: https://phabricator.services.mozilla.com/D73413
These support the new implementation of the addon blocklist (bug 1620621),
which is a more space-efficient way to represent the blocklist.
A comparison of file size was given in D73159. In short, 913KB for the
old JSON-based blocklist (addons.json), 64KB for the new one.
In practice, addons.json is 273KB compressed.
The new blocklist (addons-mlbf.bin) does not compress that well since it
is already an efficiently packed binary format.
Differential Revision: https://phabricator.services.mozilla.com/D73438
This test uses the Kinto client to access the RemoteSettings database.
However, due to the database version bump from D72416, the kinto client
is no longer compatible with the RemoteSettings database.
This will be fixed in bug 1634203.
Differential Revision: https://phabricator.services.mozilla.com/D73160
The MLBF (addons-mlbf.bin) itself is 64 KB.
Together with the metadata, this is 65 KB.
In contrast, the current JSON-based dump (addons.json) is 913 KB.
Differential Revision: https://phabricator.services.mozilla.com/D73159
With this piece, it is now possible for RemoteSettings clients to always
have a valid attachment.
This adds the client APIs that could support bug 1542177.
Differential Revision: https://phabricator.services.mozilla.com/D72417
The current RemoteSettings API has two methods for downloading:
- `download(record)` to download an attachment to disk, with a filename
given by the record. The file is read and returned before downloading.
A new download attempt overwrites the file, with no recovery mechanism
if the download fails.
- `downloadAsBytes(record)` to download an attachment in memory.
The `download` method does have a cache, but it is only useful for
reducing bandwidth usage, not for availability of data. Moreover, if its
associated record is removed from the collection, then callers do not
have a way to delete the file since its identifier (filename) originates
from the record.
The `downloadAsBytes` method does not have this file tracking issue
since it does not persist the data, but it forces callers to implement
their own attachment storing mechanism.
This commit adds the `useCache` option to the `download()` method to
enable callers to use an IndexedDB-based cache instead of the
filesystem. The following options unlock significant features:
- `fallbackToCache` - If the requested attachment is not available, the
last known attachment is returned.
- `fallbackToDump` - If the requested attachment is not available, nor
cached, then the attachment (dump) that is packaged with the client is
returned instead. This is implemented in the next commit (D72417).
The original record is cached along with the attachment, to allow
callers to use the file (identified by the given `attachmentId`) and
its metadata, even when the original record has been removed from the
collection.
This is particularly useful for scenarios where one wants to keep a file
(and metadata) up to date via RemoteSettings, without having to develop
a separate storage and synchronization mechanism.
The deprecation of the old behavior will be handled in bug 1634127.
Differential Revision: https://phabricator.services.mozilla.com/D72416
This test uses the Kinto client to access the RemoteSettings database.
However, due to the database version bump from D72416, the kinto client
is no longer compatible with the RemoteSettings database.
This will be fixed in bug 1634203.
Differential Revision: https://phabricator.services.mozilla.com/D73160
The MLBF (addons-mlbf.bin) itself is 64 KB.
Together with the metadata, this is 65 KB.
In contrast, the current JSON-based dump (addons.json) is 913 KB.
Differential Revision: https://phabricator.services.mozilla.com/D73159
With this piece, it is now possible for RemoteSettings clients to always
have a valid attachment.
This adds the client APIs that could support bug 1542177.
Differential Revision: https://phabricator.services.mozilla.com/D72417
The current RemoteSettings API has two methods for downloading:
- `download(record)` to download an attachment to disk, with a filename
given by the record. The file is read and returned before downloading.
A new download attempt overwrites the file, with no recovery mechanism
if the download fails.
- `downloadAsBytes(record)` to download an attachment in memory.
The `download` method does have a cache, but it is only useful for
reducing bandwidth usage, not for availability of data. Moreover, if its
associated record is removed from the collection, then callers do not
have a way to delete the file since its identifier (filename) originates
from the record.
The `downloadAsBytes` method does not have this file tracking issue
since it does not persist the data, but it forces callers to implement
their own attachment storing mechanism.
This commit adds the `useCache` option to the `download()` method to
enable callers to use an IndexedDB-based cache instead of the
filesystem. The following options unlock significant features:
- `fallbackToCache` - If the requested attachment is not available, the
last known attachment is returned.
- `fallbackToDump` - If the requested attachment is not available, nor
cached, then the attachment (dump) that is packaged with the client is
returned instead. This is implemented in the next commit (D72417).
The original record is cached along with the attachment, to allow
callers to use the file (identified by the given `attachmentId`) and
its metadata, even when the original record has been removed from the
collection.
This is particularly useful for scenarios where one wants to keep a file
(and metadata) up to date via RemoteSettings, without having to develop
a separate storage and synchronization mechanism.
The deprecation of the old behavior will be handled in bug 1634127.
Differential Revision: https://phabricator.services.mozilla.com/D72416
This adds abort handlers to Database.jsm and RemoteSettingsWorker.js's
indexedDB transactions, so we handle transaction aborts appropriately
and do not leave consumers waiting forever.
It also adds explicit error passing to places where we continue operating on a
store via a live transaction after control flow passes back to executeIDB,
because we use the `onsuccess` handler of earlier IDBRequests to run more
requests in the transaction.
In this case, in theory exceptions get handled by IndexedDB by invoking the
abort handler on the transaction (which we do not have right now...), but as a
belt-and-braces approach, it's probably better to do this explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D71326
These two tests use the Kinto client to access the RemoteSettings
database. However, due to the database version bump from D72416,
the kinto client is no longer compatible with the RemoteSettings
database.
This will be fixed in bug 1634203.
Differential Revision: https://phabricator.services.mozilla.com/D73160
The MLBF (addons-mlbf.bin) itself is 64 KB.
Together with the metadata, this is 65 KB.
In contrast, the current JSON-based dump (addons.json) is 913 KB.
Differential Revision: https://phabricator.services.mozilla.com/D73159
With this piece, it is now possible for RemoteSettings clients to always
have a valid attachment.
This adds the client APIs that could support bug 1542177.
Differential Revision: https://phabricator.services.mozilla.com/D72417
The current RemoteSettings API has two methods for downloading:
- `download(record)` to download an attachment to disk, with a filename
given by the record. The file is read and returned before downloading.
A new download attempt overwrites the file, with no recovery mechanism
if the download fails.
- `downloadAsBytes(record)` to download an attachment in memory.
The `download` method does have a cache, but it is only useful for
reducing bandwidth usage, not for availability of data. Moreover, if its
associated record is removed from the collection, then callers do not
have a way to delete the file since its identifier (filename) originates
from the record.
The `downloadAsBytes` method does not have this file tracking issue
since it does not persist the data, but it forces callers to implement
their own attachment storing mechanism.
This commit adds the `useCache` option to the `download()` method to
enable callers to use an IndexedDB-based cache instead of the
filesystem. The following options unlock significant features:
- `fallbackToCache` - If the requested attachment is not available, the
last known attachment is returned.
- `fallbackToDump` - If the requested attachment is not available, nor
cached, then the attachment (dump) that is packaged with the client is
returned instead. This is implemented in the next commit (D72417).
The original record is cached along with the attachment, to allow
callers to use the file (identified by the given `attachmentId`) and
its metadata, even when the original record has been removed from the
collection.
This is particularly useful for scenarios where one wants to keep a file
(and metadata) up to date via RemoteSettings, without having to develop
a separate storage and synchronization mechanism.
The deprecation of the old behavior will be handled in bug 1634127.
Differential Revision: https://phabricator.services.mozilla.com/D72416
This commit wires up `StorageSyncArea::teardown()` to call the new
`webext_storage::Store::close()` method.
It also changes `teardown` to drop the `LazyStore`, and thus close its
database connection, on the main thread if dispatching to the task
queue fails. Dispatch should only fail at shutdown, and putting the
owned reference back only adds indirection, since the `StorageSyncArea`
will still drop its `LazyStore` later in shutdown.
Finally, it includes an xpcshell test fix for
https://github.com/mozilla/application-services/pull/3050.
Differential Revision: https://phabricator.services.mozilla.com/D72992
Now that `BridgedEngine` has been moved to `sync15_traits`, we can
remove `golden_gate_traits` from the tree, and change Golden Gate to
depend on `sync15_traits` directly.
This commit also adds a Cargo feature, `services_sync`, which reflects
the `MOZ_SERVICES_SYNC` config option. In the future, we'll use this
feature to gate implementations of `mozIBridgedSyncEngine`.
Differential Revision: https://phabricator.services.mozilla.com/D72784
This commit adds a new crate for bridging Rust Sync engines to Desktop,
and a `mozIBridgedSyncEngine` for accessing the bridge via JS.
Naturally, the bridge is called Golden Gate. 😊 For more information
on how to use it, please see `golden_gate/src/lib.rs`.
Other changes include:
* Ensuring the test Sync server uses UTF-8 for requests and responses.
* Renaming `mozISyncedBookmarksMirrorLogger` to `mozIServicesLogger`,
and moving it into the shared Sync interfaces.
The `BridgedEngine` trait lives in its own crate, called
`golden_gate_traits`, to make it easier to eventually move into a-s.
`Interruptee` and `Interrupted` already exist in a-s, and are
duplicated in this crate for now.
Differential Revision: https://phabricator.services.mozilla.com/D65268
--HG--
extra : moz-landing-system : lando
Florian Quèze
Vlad Filippov
Noemi Erli
Sid Stamm
Csoregi Natalia
Edouard Oger
Mark Hammond
ffxbld
Lina Cambridge
Michael Kaply
Mark Banner
Bogdan Tara
Cosmin Sabou
Vijay Budhram
Gijs Kruitbosch
Andrea Marchesini
Coroiu Cristina
Dorel Luca
Ryan Kelly
Ian Moody
Mathieu Leplatre
Razvan Maries
Mihai Alexandru Michis
Mozilla Releng Treescript
Rob Wu
Stefan Hindli
Dale Harvey
vladikoff
jayati