This commit changes `Store::local_row_to_item` to validate local URLs,
and flags items with malformed URLs as invalid. These items are either
replaced with valid remote copies, if they exist, or deleted if not.
Additionally, `BaseBookmarksStore#_calculateIndex` no longer throws
when determining the sort index for an item with an invalid URL.
As an aside, we use the `url` crate to parse URLs. This is the same
crate as used by `MozURL`, which, in turn, backs the JS `URL`
constructor...so URLs should be validated the same way in Rust and JS.
Differential Revision: https://phabricator.services.mozilla.com/D64695
--HG--
extra : moz-landing-system : lando
This is a narrow patch that simply adds a `maxMatches` param to `PlacesRemoteTabsAutocompleteProvider.getMatches`.
Differential Revision: https://phabricator.services.mozilla.com/D50019
--HG--
extra : moz-landing-system : lando
Instead of using the list of FxA devices from the Sync clients engine,
we now fetch the list of Send Tab devices from FxA. This works like
this:
* `FxAccountsDevice#getDeviceList` has been split up into
`recentDeviceList` and `refreshDeviceList`.
* `recentDeviceList` synchronously returns the last fetched list, so
that consumers like Send Tab can use it right away.
* `refreshDeviceList` is asynchronous, and refreshes the last fetched
list. Refreshes are limited to once every minute by default, matching
the minimum sync interval (Send Tab passes the `ignoreCached` option
to override the limit if the user clicks the "refresh" button).
Concurrent calls to `refreshDeviceList` are also serialized, to
ensure the list is only fetched once.
* The list is flagged as stale when a device is connected or
disconnected. It's still kept around, but the next call to
`refreshDeviceList` will fetch a new list from the server.
* The Send Tab UI refreshes FxA devices in the background. Matching FxA
devices to Sync client records is best effort; we don't do it if Sync
isn't configured or hasn't run yet. This only impacts the fallback
case if the target doesn't support FxA commands.
Differential Revision: https://phabricator.services.mozilla.com/D47521
--HG--
extra : moz-landing-system : lando
This commit introduces a new `Watchdog` class that signals an abort,
either after a delay or at shutdown, and wires up the buffered engine
to use it.
Differential Revision: https://phabricator.services.mozilla.com/D41311
--HG--
extra : moz-landing-system : lando
Specifically, a "control pref" for a pref must already exist locally, or
a new preference, `services.sync.prefs.dangerously_allow_arbitrary` must
be set to true.
This also removes a few preferences from the set we sync by default based
due to potential harm which can be caused syncing inappropriate values.
Differential Revision: https://phabricator.services.mozilla.com/D29775
--HG--
extra : moz-landing-system : lando
Before this commit, we used event telemetry to record timing and counts
for the different steps of a bookmark merge (fetching the local tree,
new local contents, remote tree, and new remote contents; merging;
applying; fetching outgoing records; and notifying observers).
This has several limitations. We need to store all numbers as strings,
include a "flow ID" to tag events from the same merge, and collect
failure reasons twice. We also can't correlate these events to the
existing engine telemetry, meaning we can't see other stats for that
engine, or for the entire sync. Finally, we need to run separate
queries on these events for analysis, instead of extending our
existing engine dashboards.
This approach also feels like an abuse of event telemetry, so this
commit adds a "steps" field for each engine in the Sync ping. Each step
has a name, time taken, and additional named counts, like the number of
items in the tree, or merged structure stats.
Currently, only the `buffered-bookmarks` engine records these steps.
Differential Revision: https://phabricator.services.mozilla.com/D33411
--HG--
extra : moz-landing-system : lando
This commit introduces a `mozISyncedBookmarksMirrorProgressListener`
interface for capturing telemetry and updating shutdown blocker state
after each step of the merge, instead of waiting until the end. This
also means we can also record events for interrupted and failed merges,
and pass validation data through to the Sync ping.
Shutdown hang crash reports now have a `steps` field, indicating the
sequence of completed steps and when they were recorded. If the last
step in the hang report is `fetchLocalTree`, we know the merger is
blocked on `fetchNewLocalContents`. If the last step is
`fetchNewLocalContents`, the merger is stuck at `fetchRemoteTree`,
since that's the next step after `fetchNewLocalContents`.
This commit also implements `Driver::record_telemetry_event` to
dispatch progress callback runnables to the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D31950
--HG--
extra : moz-landing-system : lando
This commit exports livemarks before syncing for the first time, to
avoid losing livemarks that Sync may have resurrected. As of v0.2.4,
Dogear treats livemarks as non-syncable, and deletes them on both
sides.
This also bumps the mirror schema version, to trigger a first sync.
Differential Revision: https://phabricator.services.mozilla.com/D28543
--HG--
extra : moz-landing-system : lando
`Async.jankYielder` is known to, unfortunately, cause jank by creating a lot of
immediately resolved promises that must be then GCed. For a collection of 50
items, it will create 50 promises and 49 of them will immediately resolve.
Instead of `Async.jankYielder`, we now have `Async.yieldState`, which simply
keeps track of whether or not the caller should yield to the event loop. Two
higher level looping constructs are built on top of it:
* `Async.yieldingIterator`, which has been rewritten to not create extraneous
promises; and
* `Async.yieldingForEach`, which is a replacement for awaiting
`Async.jankYielder` in a loop. Instead, it accepts the loop body as a
function.
Each of these can share an instance of an `Async.yieldState`, which allows an
object with multiple loops to yield every N iterations overall, instead of
every N iterations of each loop, which keeps the behaviour of using one
`Async.jankYielders` in multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D26229
--HG--
extra : moz-landing-system : lando
`Async.jankYielder` is known to, unfortunately, cause jank by creating a lot of
immediately resolved promises that must be then GCed. For a collection of 50
items, it will create 50 promises and 49 of them will immediately resolve.
Instead of `Async.jankYielder`, we now have `Async.yieldState`, which simply
keeps track of whether or not the caller should yield to the event loop. Two
higher level looping constructs are built on top of it:
* `Async.yieldingIterator`, which has been rewritten to not create extraneous
promises; and
* `Async.yieldingForEach`, which is a replacement for awaiting
`Async.jankYielder` in a loop. Instead, it accepts the loop body as a
function.
Each of these can share an instance of an `Async.yieldState`, which allows an
object with multiple loops to yield every N iterations overall, instead of
every N iterations of each loop, which keeps the behaviour of using one
`Async.jankYielders` in multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D26229
--HG--
extra : moz-landing-system : lando
`Async.jankYielder` is known to, unfortunately, cause jank by creating a lot of
immediately resolved promises that must be then GCed. For a collection of 50
items, it will create 50 promises and 49 of them will immediately resolve.
Instead of `Async.jankYielder`, we now have `Async.yieldState`, which simply
keeps track of whether or not the caller should yield to the event loop. Two
higher level looping constructs are built on top of it:
* `Async.yieldingIterator`, which has been rewritten to not create extraneous
promises; and
* `Async.yieldingForEach`, which is a replacement for awaiting
`Async.jankYielder` in a loop. Instead, it accepts the loop body as a
function.
Each of these can share an instance of an `Async.yieldState`, which allows an
object with multiple loops to yield every N iterations overall, instead of
every N iterations of each loop, which keeps the behaviour of using one
`Async.jankYielders` in multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D26229
--HG--
extra : moz-landing-system : lando
This commit:
* Uses chunking to insert child GUIDs in `storeRemoteFolder`.
* Changes the mirror schema to store diverging structure, so that it
can be passed to Dogear.
* Sorts remote items by GUID, so that diverging ones can be reparented
in a deterministic order.
* Measures and logs the time taken to run the Rust merger.
* Adds tests for multiple parents and replacing invalid remote items.
* Fixes two tests in `test_bookmark_structure_changes` to ensure the
remote structure is consistent.
Differential Revision: https://phabricator.services.mozilla.com/D26275
--HG--
extra : moz-landing-system : lando
AddonManagergetInstallForURL() has a number of optional arguments, most
of which are passed infrequently. Convert them from positional arguments
to a single options object.
Differential Revision: https://phabricator.services.mozilla.com/D18475
--HG--
extra : rebase_source : 503c09b54fab90cefe69286b05def43ef70074df
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This patch disables a couple of tests, removes old async support from TPS,
and puts more effort into preventing Syncs while TPS is running, and
removed an unused import.
Differential Revision: https://phabricator.services.mozilla.com/D8692
--HG--
extra : moz-landing-system : lando
ffxbld
Mark Banner
Lina Cambridge
Siddhant085
shindli
Mark Hammond
Thom Chiovoloni
lougenia
Cosmin Sabou
Drew Willcoxon
Sam Foster
Edouard Oger
Bogdan Tara
Nicholas Nethercote
Jared Wein
Victor Porof
Boris Zbarsky
Matthew Noorenberghe
Coroiu Cristina
Michael Kaply
Barret Rennie
Csoregi Natalia
Noemi Erli
Kris Maglione
Andrew Swan
Myk Melez
Sebastian Hengst