Bug 1541804: Make profile refresh for non-ascii named profiles work correctly. r=Gijs a=pascalc
authorDave Townsend <dtownsend@oxymoronical.com>
Tue, 09 Apr 2019 12:28:49 +0300
changeset 526064 19e1fc9a203cb2f4c4b9b1ae5a5dfac2bafeb2f2
parent 526063 0dfc99259470484235be9779a886ed8e7d95b22f
child 526065 ee9092819df0f8f67de4e97abfc0d1b216790ec7
push id2032
push userffxbld-merge
push dateMon, 13 May 2019 09:36:57 +0000
treeherdermozilla-release@455c1065dcbe [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersGijs, pascalc
bugs1541804, 1322797
Bug 1541804: Make profile refresh for non-ascii named profiles work correctly. r=Gijs a=pascalc Summary: This fixes two bugs. The first is that when the firefox profile migrator doesn't know which profile to migrate it attempts to fall back to another profile. I think this was intended to be the default but in bug 1322797 I ended up making it the current profile, which is the profile we're restoring into now. I think at this stage the profile directory doesn't even exist so things go wrong. Changing to use the actual default works but.... When the profile migrator UI doesn't know what profile to migrate from it uses the default profile. So if the profile you're actually trying to restore is not the default we'll effectively throw its data into the archive and replace it with data from the default profile. I'm inclined to say that if the migrator does not know what profile to migrate from it should error at that point for safety. Why would the profile migrator not know what profile to migrate from? Because of a long-standing text encoding problem. In C++ profile names are encoded in UTF8. But we try to pass them to JS through an IDL parameter of type ACString. This does no UTF8 decoding and so JS recieves an incorrect name if the name includes non-ascii characters and so can't find the profile. This patch fixes the IDL parameter to AUTF8String which does the decoding correctly and so JS gets the name correctly. We should probably think about whether just passing the nsIToolkitProfile object to the migrator is a better choice here. Reviewers: Gijs Reviewed By: Gijs Subscribers: MattN Bug #: 1541804 Differential Revision: https://phabricator.services.mozilla.com/D26250
--- a/browser/components/migration/FirefoxProfileMigrator.jsm
+++ b/browser/components/migration/FirefoxProfileMigrator.jsm
@@ -66,17 +66,17 @@ FirefoxProfileMigrator.prototype._getFil
   // copy non-existing files.
   return file.exists() ? file : null;
 FirefoxProfileMigrator.prototype.getResources = function(aProfile) {
   let sourceProfileDir = aProfile ? this._getAllProfiles().get(aProfile.id) :
-      .currentProfile.rootDir;
+      .defaultProfile.rootDir;
   if (!sourceProfileDir || !sourceProfileDir.exists() ||
     return null;
   // Being a startup-only migrator, we can rely on
   // MigrationUtils.profileStartup being set.
   let currentProfileDir = MigrationUtils.profileStartup.directory;
--- a/toolkit/profile/nsIProfileMigrator.idl
+++ b/toolkit/profile/nsIProfileMigrator.idl
@@ -56,14 +56,14 @@ interface nsIProfileMigrator : nsISuppor
    * @param  aStartup nsIProfileStartup object to use during migration.
    * @param  aKey     optional key of a migrator to use to skip source selection.
    * @param  aProfileName optional name of the profile to use for migration.
    * @note The startup code ignores COM exceptions thrown from this method.
   void migrate(in nsIProfileStartup aStartup, in ACString aKey,
-               [optional] in ACString aProfileName);
+               [optional] in AUTF8String aProfileName);
 #define NS_PROFILEMIGRATOR_CONTRACTID "@mozilla.org/toolkit/profile-migrator;1"