When bug 1433324 made these tests run against activity stream, it made the notification
fire from the test's head.js file itself. Unfortunately, that races with the new tab / home
page actually loading, triggering an `onLocationChange` event in the tabbrowser, which
removes the notification again, meaning it is then no longer there when the test expects
it to be.
This wasn't an issue before, because the notification bar was opened via a message from
within the new tab page, which always arrived after the `onLocationChange` event.
Because the current state is temporary anyway, I'm just changing the test to open 2 tabs
first, and then opening the notification bars, which in practice guarantees this happens
after the `onLocationChange` event.
MozReview-Commit-ID: LOzgjrZBp0H
--HG--
extra : rebase_source : 10568c1ad97b03143d79b2d967ccac42550000a6
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
This removes all the homepage-related code. All the cases where we advance the wizard straight to
the homepage wizardpage now go straight to the 'start migrating' page (the 'point' was skipping
earlier pages that allowed users to select items).
The brand bundle was only used by the homepage code so is also being removed.
MozReview-Commit-ID: I9nSU2IMkQz
--HG--
extra : rebase_source : da803ed67b443cb164f2bc55550bfd7c107fa916
Removed a fallback import from a legacy FHR file when there is no valid ID in the DRS file.
This commit is related to bug 1431544
MozReview-Commit-ID: AACq7InWJpy
--HG--
extra : rebase_source : c48bf48addc515b9d86f22dd4e8ad5a066ebc76a
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
Now that the interfaces are all async, we can simply replace all
the sync IO in the Chrome migrator with the equivalent async IO.
Other browsers will be addressed in separate patches.
MozReview-Commit-ID: FyGRRKY57Gm
--HG--
extra : rebase_source : 0228b9b72c7217e3f6e607256cb3828bf5819189
migration.js is a special case where we generally need blocking
calls in order for the wizard to work correctly. Accordingly we
block waiting for the new async interfaces. With automigration
and potential new UIs that are in the works for migration, the
asynchronicity of these interfaces will be more relevant, but
here it's not really important enough to make big changes to the
way the UI is implemented.
MozReview-Commit-ID: LkfwBVfpCJO
--HG--
extra : rebase_source : 1f9f2c7e2fa20b883840e091dbee366a161eaaf7
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
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
getLastUsedDate should be converting the microseconds of typedURLs
into milliseconds.
MozReview-Commit-ID: DjJKm5aPcGD
--HG--
extra : rebase_source : 017a33f2599b779403988997145d5d1a9acdf109
Edge history visit times can be zero. Not sure of exactly what
conditions cause this, but the Edge start page has a visit time of
0 on a local machine.
MozReview-Commit-ID: KJ9iwbLIhj2
--HG--
extra : rebase_source : 726461a6acb6a58c7b45c9e2f1ceb7e911a83c72
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
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