As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
Except observers, which will be handled in the last commit of this series.
MozReview-Commit-ID: IvwyleXBcNH
--HG--
extra : rebase_source : 8054777b015c3b07c6599bdb00c9d32572313395
Also move promiseStopServer to the common/ head_helpers.js
MozReview-Commit-ID: B3Idnj6rPAZ
--HG--
extra : rebase_source : adb07d381aca118b9b49971f87e68a239dbcfb70
Except observers, which will be handled in the last commit of this series.
MozReview-Commit-ID: IvwyleXBcNH
--HG--
extra : rebase_source : 8054777b015c3b07c6599bdb00c9d32572313395
Also move promiseStopServer to the common/ head_helpers.js
MozReview-Commit-ID: B3Idnj6rPAZ
--HG--
extra : rebase_source : adb07d381aca118b9b49971f87e68a239dbcfb70
Except observers, which will be handled in the last commit of this series.
MozReview-Commit-ID: IvwyleXBcNH
--HG--
extra : rebase_source : b5f9fe43ac2fd956253c571f4cc7b68eb1d928ec
Also move promiseStopServer to the common/ head_helpers.js
MozReview-Commit-ID: B3Idnj6rPAZ
--HG--
extra : rebase_source : 0c3ee2b37448467fdd7fec04dbdf39255608901b
Except observers, which will be handled in the last commit of this series.
MozReview-Commit-ID: IvwyleXBcNH
--HG--
extra : rebase_source : b5f9fe43ac2fd956253c571f4cc7b68eb1d928ec
Also move promiseStopServer to the common/ head_helpers.js
MozReview-Commit-ID: B3Idnj6rPAZ
--HG--
extra : rebase_source : 0c3ee2b37448467fdd7fec04dbdf39255608901b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This patch adds a new bookmarks engine, pref'd off, that writes to the
buffer instead of Places.
MozReview-Commit-ID: 7idBa03kOzm
--HG--
extra : rebase_source : 671ebeb3de824dc43c0ef14b2dfe065a33e2911a
The mirror matches the complete bookmark tree stored on the Sync
server, stores new bookmarks changed on the server since the last
sync, merges the local and remote trees, applies the resulting merged
tree back to Places, fires observer notifications for all items changed
in the merge, and stages locally changed bookmarks for upload.
MozReview-Commit-ID: MbeFQUargt
--HG--
extra : rebase_source : b635fd65ef10ab9ce3a2f9af2e527d342a790f6e
Fairly straightforward. Fixes the tests that were broken due to
the changes introduced in part 1.
MozReview-Commit-ID: GbZ9ZpmG9nE
--HG--
extra : rebase_source : ebb2088288718631a941139d5a4d945259aaa0c6
There's a heavy enough overhead to going through XPConnect for
every observer for every visit on the nsINavHistoryObserver
interface, so this patch reduces that by replacing the single-
visit notification with one which accepts an array of visits.
Some notes: To avoid problems with the orderings of the various
ways in which we notify about visits, we have to send our bulk
onVisits notification before doing any of the others. This does
mean it technically behaves slightly different than the prior
approach of interleaving the notifications, but I can't find any
way in which this has any consequences to the end result, and it
doesn't break any tests.
MozReview-Commit-ID: GdeooH8mCkg
--HG--
extra : rebase_source : 48b5f886c4650a756e70f4657cb9d62c8ce40f74
The requested URL was logged on almost each failing request exception.
Added a warn message to log the request method and url when any request fails.
MozReview-Commit-ID: GKwd7HabTp6
--HG--
extra : rebase_source : 012bb9c322ecda93be32f43582492b37e407396d
This uses a similar strategy as that employed by moz_places_afterdelete_trigger,
creating a temp table which we write host inserts into, and then deleting all
the rows from it when we're done inserting, effectively resulting in a per-
statement trigger to only do the significant work per host.
MozReview-Commit-ID: 5TUueknq3ng
--HG--
extra : rebase_source : 1892edfcaa7b6afd29ce794a93d6ab3d46c48895
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : b885ee784704819e181430200af5ef762e269d14
MozReview-Commit-ID: LLTg0ae5BbW
***
Bug 1414438 - Use `getBatched` instead of `get` in sync
--HG--
extra : rebase_source : b9b057160470ec5bc5544a1a4d5d429bee460452
Using `nsISecretDecoderRing` directly bypasses
`nsILoginManagerCrypto.uiBusy` and the observer notifications, so other
consumers might not be aware we're already showing the dialog. We also
bail early if the UI is busy, to avoid showing multiple dialogs.
MozReview-Commit-ID: I7xzUWZkyPH
--HG--
extra : rebase_source : 91cef140cc54d1c81fe5c1986ffd2b8983ddd575
It's no longer needed, now that legacy extensions aren't supported.
Pieces removed include the following.
- The "load-extension-default" observer notification.
- The code for reading defaults/preferences/*.js from extensions.
- The unit test for this stuff.
- A crash reporter annotation relating to very long prefs set by add-ons.
- All references to "ExtPrefDL".
MozReview-Commit-ID: KMBoYn3uZ3x
--HG--
extra : rebase_source : 4dc8ffd425c6cdf06806409090c4f9d04a64930b
* In the first stage, we fetch changed records, newest first, up to the
download limit. We keep track of the oldest record modified time we
see.
* Once we've fetched all records, we reconcile, noting records that
fail to decrypt or reconcile for the next sync. We then ask the store
to apply all remaining records. Previously, `applyIncomingBatchSize`
specified how many records to apply at a time. I removed this because
it added an extra layer of indirection that's no longer necessary,
now that download batching buffers all records in memory, and all
stores are async.
* In the second stage, we fetch IDs for all remaining records changed
between the last sync and the oldest modified time we saw in the
first stage. We *don't* set the download limit here, to ensure we
add *all* changed records to our backlog, and we use the `"oldest"`
sort order instead of `"index"`.
* In the third stage, we backfill as before. We don't want large deltas
to delay other engines from syncing, so we still only take IDs up to
the download limit from the backlog, and include failed IDs from the
previous sync. On subsequent syncs, we'll keep fetching from the
backlog until it's empty.
Other changes to note in this patch:
* `Collection::_rebuildURL` now allows callers to specify both `older`
and `newer`. According to :rfkelly, this is explicitly and
intentionally supported.
* Tests that exercise `applyIncomingBatchSize` are gone, since that's
no longer a thing.
* The test server now shuffles records if the sort order is
unspecified.
MozReview-Commit-ID: 4EXvNOa8mIo
--HG--
extra : rebase_source : f382f0a883c5aa1f6a4466fefe22ad1a88ab6d20
The test captures the existing logic in `_processIncoming`, even though
it's not quite correct:
* First, we fetch all records changed since the last sync, up to the
download limit, and without an explicit sort order. This happens to
work correctly now because the Python server uses "newest" by
default, but can change in the future.
* If we reached the download limit fetching records, we request
IDs for all records changed since the last sync, also up to the
download limit, and sorted by index. This is likely to return IDs
for records we've already seen, since the index is based on the
frecency. It's also likely to miss IDs for other changed records,
because the number of changed records might be higher than the
download limit.
* Since we then fast-forward the last sync time, we'll never download
any remaining changed records that we didn't add to our backlog.
* Finally, we backfill previously failed and backlogged records.
MozReview-Commit-ID: 7uQLXMseMIU
--HG--
extra : rebase_source : 719ee2d9e46102195251b410f093da3247095c22
* In the first stage, we fetch changed records, newest first, up to the
download limit. We keep track of the oldest record modified time we
see.
* Once we've fetched all records, we reconcile, noting records that
fail to decrypt or reconcile for the next sync. We then ask the store
to apply all remaining records. Previously, `applyIncomingBatchSize`
specified how many records to apply at a time. I removed this because
it added an extra layer of indirection that's no longer necessary,
now that download batching buffers all records in memory, and all
stores are async.
* In the second stage, we fetch IDs for all remaining records changed
between the last sync and the oldest modified time we saw in the
first stage. We *don't* set the download limit here, to ensure we
add *all* changed records to our backlog, and we use the `"oldest"`
sort order instead of `"index"`.
* In the third stage, we backfill as before. We don't want large deltas
to delay other engines from syncing, so we still only take IDs up to
the download limit from the backlog, and include failed IDs from the
previous sync. On subsequent syncs, we'll keep fetching from the
backlog until it's empty.
Other changes to note in this patch:
* `Collection::_rebuildURL` now allows callers to specify both `older`
and `newer`. According to :rfkelly, this is explicitly and
intentionally supported.
* Tests that exercise `applyIncomingBatchSize` are gone, since that's
no longer a thing.
* The test server now shuffles records if the sort order is
unspecified.
MozReview-Commit-ID: 4EXvNOa8mIo
--HG--
extra : rebase_source : 13605dd3a43569a6d83dc2eb15a578a7bbd5c1ca
The test captures the existing logic in `_processIncoming`, even though
it's not quite correct:
* First, we fetch all records changed since the last sync, up to the
download limit, and without an explicit sort order. This happens to
work correctly now because the Python server uses "newest" by
default, but can change in the future.
* If we reached the download limit fetching records, we request
IDs for all records changed since the last sync, also up to the
download limit, and sorted by index. This is likely to return IDs
for records we've already seen, since the index is based on the
frecency. It's also likely to miss IDs for other changed records,
because the number of changed records might be higher than the
download limit.
* Since we then fast-forward the last sync time, we'll never download
any remaining changed records that we didn't add to our backlog.
* Finally, we backfill previously failed and backlogged records.
MozReview-Commit-ID: 7uQLXMseMIU
--HG--
extra : rebase_source : 5742474889845b934c3d2e8b479d26d719cd03c0
