This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
In bug 1426721 we added a bulk interface for importing logins, which
works in a background thread. This patch cleans up the single-login
interface and updates the remaining usages to consume the bulk
interface.
MozReview-Commit-ID: IziLXkO5dxQ
In bug 1426721 we added a bulk interface for importing logins, which
works in a background thread. This patch cleans up the single-login
interface and updates the remaining usages to consume the bulk
interface.
MozReview-Commit-ID: IziLXkO5dxQ
In bug 1426721 we added a bulk interface for importing logins, which
works in a background thread. This patch cleans up the single-login
interface and updates the remaining usages to consume the bulk
interface.
MozReview-Commit-ID: IziLXkO5dxQ
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
Fairly trivial. This was breaking for the test_refresh_firefox
test in beta, since the code which calls this is only active if
certain branding strings are present.
MozReview-Commit-ID: 3CkosXHgoMm
A significant chunk of migration jank that I observe locally
happens due to login encryption. This patch reduces the locally
observed jank (measured importing 100 logins) from 180ms to 25ms.
Try is green, and as far as I can tell I don't see any thread
safety issues, but I'm not 100% sure on that. I don't see any
red flags inside the SecretDecoderRing::Encrypt implementation.
I only moved Chrome logins over since I wanted to frontload any
potential issues with the whole approach. It shouldn't be too
hard to move the MSMigrationUtils and IEProfileMigrator uses
over though.
MozReview-Commit-ID: 75edUqJlk8x
In order to clean up sync IO within our profile migrators, we
need to have async interfaces for those parts which are currently
doing sync IO. This converts the sync interfaces and adjusts most
of the call sites (migration.js call site changes are addressed
in a separate patch to break it out a bit).
MozReview-Commit-ID: 2Kcrxco4iYr
To reduce any contention from migrating multiple resources at the
same time, it seems prudent to wait for each to finish before
migrating the next. res.migrate is only sometimes properly async,
so the simplest thing to do today is to just always await
completeDeferred.promise. Additionally I am filing Bug 1418455
to track simplifying this to simply await res.migrate.
MozReview-Commit-ID: LdgNsxfuzu4
setTimeout was previously undefined. Created a test specifically
for MigrationUtils, since trying to test this through an actual
Chrome migration path seemed trickier and more fragile.
MozReview-Commit-ID: 33U7ZzzG1CC
setTimeout was previously undefined. Created a test specifically
for MigrationUtils, since trying to test this through an actual
Chrome migration path seemed trickier and more fragile.
MozReview-Commit-ID: 33U7ZzzG1CC
The MigrationUtils change is because 99% of the time we will only have
1 visit per URI, and so we spend silly amounts of time doing nothing.
Time spent in composing our undo structure went from ~800ms to ~550ms
with this change.
The other change just seemed obvious - when visits aren't recent,
we shouldn't add them to 'recently visited' lists, which seem to use
'time this function was called' as the time associated with an entry,
which is incorrect.
MozReview-Commit-ID: 2I0D5ApOCI7
When updating a large number of places, sending runnables to the main thread
for every single one of them whose frecency we update is not conducive to a
responsive UI. This only gets worse once more observers care about these
notifications (e.g. when the library is open).
To avoid this on startup when importing from other browsers, this patch adds
and uses an option to group the frecency notifications. Later patches will
also use the option to avoid other notifications where possible.
MozReview-Commit-ID: D5KqPDu86bo