Affected versions

• 67.0.1;

Affected platforms

• Windows 7/10, macOS 10.14/10.14.5, Ubuntu 16.04/18.04;

Steps to reproduce
Pre: have some browsing data, bookmarks, user+password saved on the Chrome browser;

1. Launch the Firefox .exe from the CMD terminal with firefox.exe -p -migration tags to force the import;
2. Create a new profile;
3. Select the Chrome browser and confirm the next steps;
4. Access any of the websites and try to login via the autocomplete data.

Expected result

• user + passwords are properly imported from other browsers;

Actual result

• user + password data is not imported;
• the Saved logins information table was also empty;

Regression range

• 66, 67.0 builds are not affected;

Additional notes

• for detailed information check this link;

If this is indeed blocking data import from Chrome, particularly in way such that the user is unaware that it failed, I would consider it a blocker.
Rationale: We expect to attract a lot of Chrome users - hitting this issue is likely to give a terrible first impression.

I'd be interested in hearing if it happens every single time or only in certain circumstances.

Are we expecting passwords to be imported? This is the import dialog shown from 67.0 after selecting Chrome

Here are some of the reasons because of which QA considers this a blocker -

• it is highly visible to the end-user migrating from Chrome or other browsers
• it adversely affects user's initial Firefox experience by not making their login info available to them
• may impact brand stickiness since users will most likely switch back to Chrome to retrieve their login info
• it a is regression in Trailhead

Given that Trailhead is targeted to encourage users to switch to Firefox, we want to ensure that the process of switching is as seamless as possible which makes this bug a blocker. Also, since there is heightened interest in switching from Chrome because of their latest news around adblock, we want to be extra cautious.

(In reply to Cristi Fogel, QA [:cfogel] from comment #0)

Affected platforms

• Windows 7/10, macOS 10.14/10.14.5, Ubuntu 16.04/18.04;
  …

Expected result

• user + password data is not imported;

Actual result

• user + passwords are properly imported from other browsers;
• the Saved logins information table was also empty;

I assume you got the expected and actual mixed up?

For one thing login import has never been supported by Chrome on macOS and Linux. See https://wiki.mozilla.org/QA/Firefox_migrators#Supported_data_types

Please also attach the Browser Console logs when you encounter the problem. I will try repro myself on Windows now.

(In reply to Ed Lee :Mardak from comment #2)

Created attachment 9069420 [details]
67.0 chrome import

Are we expecting passwords to be imported? This is the import dialog shown from 67.0 after selecting Chrome

No, not on macOS, only on Windows. See https://wiki.mozilla.org/QA/Firefox_migrators#Supported_data_types

One obvious thing to note… you can't have Chrome running while you are importing (as the database is locked)… there is a message on the first screen that tells you this once you select Chrome.

It worked for me on the en-US candidate build FWIW. I'll investigate more.

Clarifying title -- it is known and expected that importing only works on Windows (see comment 4). Question to sort out is if QA really saw a failure there or if anyone else can reproduce it.

unable to repro on Win 10. After shutting down Chrome in the background (per bugzilla comment #6 above) and after running the firefox -p -migration, Firefox installed and launched and autofilled my Kiva.org username/password.

I was also able to successfully import my saved passwords from Chrome on Windows 10 using the following 32-bit, en-CA build:
https://ftp.mozilla.org/pub/firefox/candidates/67.0.1-candidates/build1/win32/en-CA/

I was able to do the same using this one: https://ftp.mozilla.org/pub/firefox/candidates/67.0.1-candidates/build1/win64-aarch64/en-US/

When I didn't repro earlier I didn't use the -p argument but now when I tried firefox.exe -p -migration and chose a brand new profile (which wouldn't have an encryption/decryption key yet) then it did fail:

[Exception... "User canceled master password entry" nsresult: "0x80004004 (NS_ERROR_ABORT)" location: "JS frame :: resource://gre/modules/crypto-SDR.js :: encryptMany :: line 130" data: no]

I wonder if this is because NSS/PSM isn't ready because it doesn't have an encryption/decryption key yet (key4.db) and nothing waits on that? The STR didn't say whether a new or existing profile was chosen.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #12)

When I didn't repro earlier I didn't use the -p argument but now when I tried firefox.exe -p -migration and chose a brand new profile (which wouldn't have an encryption/decryption key yet) then it did fail:

[Exception... "User canceled master password entry" nsresult: "0x80004004 (NS_ERROR_ABORT)" location: "JS frame :: resource://gre/modules/crypto-SDR.js :: encryptMany :: line 130" data: no]

I wonder if this is because NSS/PSM isn't ready because it doesn't have an encryption/decryption key yet (key4.db) and nothing waits on that? The STR didn't say whether a new or existing profile was chosen.

When I tried the exact same steps again it worked fine so I think there maybe be a race between NSS/PSM and the migrator. This is unlikely to only affect Trailhead though and is more likely to affect the command line argument than UI after the browser started.

It may be useful to test with software like AVG which imports their certificate for web monitoring as that may affect when NSS/PSM is ready.

Dana, what MOZ_LOG values would be useful to debug encryptMany failing (from bug 1426721) during migration before the browser window starts? See comment 12.

I was able to get this working with a second Win10 Chrome profile as well, which had a saved reddit login. Once I ran firefox.exe -p -migration, and choose Chrome as my source, it prompted me to choose between my default Chrome profile, or my secondary pdehaan@mozilla.com profile.

You could try "pipnss:5" but it doesn't look like there is any logging specific to the backend implementation: https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/security/manager/ssl/SecretDecoderRing.cpp#144

Note that if I get the failure importing passwords from -migration then PSM gets stuck in the broken state so I can't run a migration from the UI afterwards. I get the same error from encryptMany, no key4.db gets created.

Mardak confirms that bug 1545487 removed the about:welcome UI to offer a data migration to the user (and it got uplifted to 67 in bug 1548042). This means the only way a user can hit this is to manually go to one of the other entry points and start a migration from there. I would that unless we're explicitly promoting this function to users (as part of Trailhead messaging elsewhere?) that we should ship with this bug.

Chuck agrees that this bug is no longer a blocker for the 67 Trailhead release tomorrow.

(We'll continue investigating the issue of course.)

I have never been able to reproduce this bug from the migrator entry points from within Firefox, only via -migration when combined with -p and a new profile is chosen from the profile manager.

I think this is an issue of PSM initialization possibly from being used too early before a browser window has appeared (bug 1388145 did change some timing in 57 [not 67] to move the Services.logins access earlier, it was previously in browser.js when a browser window was created but that moved it to BrowserGlue.jsm which may run during the migrator window? I haven't confirmed that).

I'm moving this bug to PSM to debug what is going wrong internally from the encryptMany call. Here are updated STR that reproduce at least 50% of the time for me on a Windows 10 VM using the candidate build:

Affected versions

• 67.0.1; About 50% of the time.
• I tried to repo 4 times on Nightly and didn't succeed.

Steps to reproduce
Prereq.: have some browsing data, bookmarks, user+password saved on the Chrome browser;
0. Close Chrome.

1. Launch firefox.exe from the CMD terminal with firefox.exe -p -migration arguments to force the migration wizard to appear.
2. Create a new profile in the profile manager
3. Select the Chrome browser and confirm the next steps;
4. Access any of the websites and try to login via the autocomplete data.

Expected result

• user + passwords are properly imported from other browsers;

Actual result

• user + password data is not imported;
• the Saved logins table was also empty;

I wanted to confirm that the bug also happened on 67.0.0 but for some reason my STR no longer work at all, even in the candidate build… all I did was install Firefox 67.0.0 on my machine from mozilla.org using the stub installer.

Hopefully the issue can still be diagnosed by inspection or by adding intentional delays in the code to change the timing.

@Matthew, thank you for the corrections and @the others for the confirmation. Updated the information in comment 0 for better readability as per c19.
As for trying to get the logs indeed, it seems to be intermittent since today we are unable to reproduce either on 2 of the (Windows)machines that were exhibiting the issue.

Just to double check, the fact that Chrome would not be closed before the import. Would that cause this issue to appear as well(lack of data imported/autofilled)?
Fwiw, for some attempts we did not do that.

(In reply to Cristi Fogel, QA [:cfogel] from comment #21)

@Matthew, thank you for the corrections and @the others for the confirmation. Updated the information in comment 0 for better readability as per c19.
As for trying to get the logs indeed, it seems to be intermittent since today we are unable to reproduce either on 2 of the (Windows)machines that were exhibiting the issue.

OK, hopefully when/if someone can reproduce again they can get the logs. Browser Console logs are often very useful for migration bugs.

Just to double check, the fact that Chrome would not be closed before the import. Would that cause this issue to appear as well(lack of data imported/autofilled)?
Fwiw, for some attempts we did not do that.

Yes, if Chrome is running (with the Chrome user/profile selected for import) while a migration is happening then many pieces of its data would not be imported. No logins can be imported because they put an exclusive lock on their database.

The priority flag is not set for this bug.
:keeler, could you have a look please?

For more information, please visit auto_nag documentation.

Closing this issue since it's appears to no longer be reproducible with the current builds (67.0.4) and as per comment #20.
If the issue reappears or after investigation someone is able to reproduce please reopen it.