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
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Patch originally by Ganesh, updated by Standard8
MozReview-Commit-ID: AihTLo5OyK1
--HG--
extra : rebase_source : f5a886326dd7f2fb2dba3309199ef277affe6b77
Fairly trivial - discussed in bug 862127. Opt to cancel the spin wait
rather than disable canceling in the UI.
MozReview-Commit-ID: B55Fsw34uX7
--HG--
extra : rebase_source : 3b7e83799af01cef096894b40537c1a4021ffc16
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
--HG--
extra : rebase_source : 5e9be186b1f112afb5bd46c1a979b3403ce3b59d
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
--HG--
extra : rebase_source : 7b2df904fde5ec0abeb7d30633b0dd819de0cc9e
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
--HG--
extra : rebase_source : 7b2df904fde5ec0abeb7d30633b0dd819de0cc9e
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
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
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
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
--HG--
extra : rebase_source : b027b12f3f09a8114ccf32c767262a32543b3a74
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
--HG--
extra : rebase_source : 0a8e16c46e05972fb01c9703b52cdb5755b0b40b
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
--HG--
extra : rebase_source : 53d123c435e43622a999a7e849dddbe1919061e0
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
--HG--
extra : rebase_source : d111110f1445ed84785523ee12b5afb3da2d7207
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
--HG--
extra : rebase_source : 499c923679f455d2b126a97ce29f579a6a93fda5
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
--HG--
extra : rebase_source : 0399d9bc768d8eb7451fbb75ec3282f903cdb4ad
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
--HG--
extra : rebase_source : 8032e6644337c6758bf5653ef0a149d4f39b0085
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
--HG--
extra : rebase_source : ad5bbce40eaa802a6a88bc0c9a9c7026fd056598