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
NOTE: This commit does not yet include a dump of the RemoteSettings
collection and attachment. This will be added in the near future.
Differential Revision: https://phabricator.services.mozilla.com/D72418
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
When remote-debugging a device, it might happen that the device clock
is not exactly at the same time as the client clock. In such case, we
may end up in cases where the result of a command as an older timestamp,
which means we could have in the console output a result that was displayed
before the command message that triggered it.
In order to fix this, we add a `startTime` property on the evaluateJSAsync
response, that we can then check on the client. If the server time is
older than the client time, then we remove the existing command message
and add a new one, with the server timestamp.
We could have waited the result of the command before displaying the
command message (so we don't have to add a message, and then remove it
when the timestamps don't match), but the UI wouldn't feel snappy, and
even worse in case of long execution times (e.g. a top-level await fetch command).
Differential Revision: https://phabricator.services.mozilla.com/D72705
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
This adds a splits the non-incremental threshold parameter into one for small heaps and one for large. What counts as large and small are controlled by the existing parameters that were previously used for dynamic heap growth. I also renamed the parameter from "non-incremental threshold" to "incremental limit".
The small heap parameter is increased to 1.4. This avoids non-incremental GC on facebook and reddit as reported in the dependent bugs and allows us to remove the splay latency hack that was previously necessary.
Differential Revision: https://phabricator.services.mozilla.com/D72903
When I tested the main patch for this bug I got test failures in the gc/gcparam.js jit-test because of rounding errors converting GC parameters between integer percentages and floats in GCSchedulingTunables::setParameter. Making these all double fixes the problem, and it's the default floating point type in C++ anyway.
Differential Revision: https://phabricator.services.mozilla.com/D72902
Simon Giesecke
Stefan Hindli
Razvan Maries
aarushivij
Rob Wu
Nicolas Chevobbe
Masayuki Nakano
Joel Maher
Florin Strugariu
Gijs Kruitbosch
Mathieu Leplatre
Mark Hammond
Mark Banner
Liang-Heng Chen
Andrea Marchesini
Jon Coppeard
David Teller