Affected versions

• 83.0b8, 84.0a1 (2020-11-04);

Affected platforms

• macOS 10.15;

Steps to reproduce

1. Have data saved in Chrome;
2. Launch Firefox;
3. Access about:logins
4. Click on the [...] button;
5. Click on the Import data from other browsers button;
6. Select Chrome, select all, go through with the import process;

Expected result

• data imported from Chrome (passwords, bookmarks, history);

Actual result

• no user account data imported;

Regression range

• not a regression;

Additional notes

• history and bookmark data is imported;
• suggested severity would be ~S4, as it might be linked to Apple Keychain acting up, still having some trouble with sorting/removing(or reseting) it for Chrome at the moment;
• as a note, the keychain password was requested on beta builds but not on nightly;
• attached one of the error logs from an unsuccessful attempt to import/migrate data.

IIRC the issue with importing logins from Keychain on mac is that each login imported would require the user to type in their Keychain password.

Tim, does this sound familiar?

Unfortunately, I'm not sure how the Keychain on Mac handles this situation. Wish I could be of more help, but I haven't had a chance to really dig in to the import from another browser logic. I've been doing some dives but nothing conclusive has popped out at me.

Edit: might have something to do with this block of ChromeProfileMigrator

This error in the output is the cause,

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIKeychainMigrationUtils.getGenericPassword]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource:///modules/ChromeMacOSLoginCrypto.jsm :: ChromeMacOSLoginCrypto :: line 90" data: no] ChromeMacOSLoginCrypto.jsm:90:31
some passwords did not successfully migrate.

Cristian, were you testing with Chrome Canary or a release build of Chrome? I see messages in the output related to Chrome Canary. Can you make sure to test with the release build of Chrome?

Looked odd to me as well.
Thing is, the installed build was Chrome not the Canary version. For good measure, one downloaded from here.
Did a quick check as well, but Canary isn't even installed on the machine/OS.

The spam in the logs relating to devtools is bug 1669666.

Still looking at the rest.

On a machine where this reproduces, if you run this in the browser console, do you get the same error:

XPCOMUtils.defineLazyServiceGetter(this, "gKeychainUtils", "@mozilla.org/profile/migrator/keychainmigrationutils;1", "nsIKeychainMigrationUtils");

gKeychainUtils.getGenericPassword("Chrome Safe Storage", "Chrome")

?

Does this reproduce on multiple devices? Is it possible you've selected "Deny" for Chrome in the past?

If you open Keychain Access.app, select the login keychain, then select "Chrome Safe Storage" in the list of application passwords (you can filter in the search box in the top right), then right click and "Get Info", what do the settings look like?

(In reply to :Gijs (he/him) from comment #7)

Does this reproduce on multiple devices? Is it possible you've selected "Deny" for Chrome in the past?

Looking at it, it's very likely that's what happened and I overlooked that step, making the report invalid.
However, before closing the bug; I'd like to confirm that the errors noted on comment 3 are expected, as they are thrown in the console as soon as the Import window is open:

Unix error 2 during operation open on file /Users/svuser/Library/Application Support/Google/Chrome Canary/Local State (No such file or directory) ChromeMigrationUtils.jsm:237
Error detecting Chrome profiles: Unix error 2 during operation open on file /Users/svuser/Library/Application Support/Google/Chrome Canary/Local State (No such file or directory)

If you open Keychain Access.app, select the login keychain, then select "Chrome Safe Storage" in the list of application passwords (you can filter in the search box in the top right), then right click and "Get Info", what do the settings look like?

Indeed, the settings are to [Confirm before allowing access].

(In reply to Cristian Fogel, QA [:cfogel] from comment #8)

(In reply to :Gijs (he/him) from comment #7)

Does this reproduce on multiple devices? Is it possible you've selected "Deny" for Chrome in the past?

Looking at it, it's very likely that's what happened and I overlooked that step, making the report invalid.
However, before closing the bug; I'd like to confirm that the errors noted on comment 3 are expected, as they are thrown in the console as soon as the Import window is open:

Unix error 2 during operation open on file /Users/svuser/Library/Application Support/Google/Chrome Canary/Local State (No such file or directory) ChromeMigrationUtils.jsm:237
Error detecting Chrome profiles: Unix error 2 during operation open on file /Users/svuser/Library/Application Support/Google/Chrome Canary/Local State (No such file or directory)

Yeah, they indicate you have no Chrome Canary profiles. We should probably suppress the errors and/or make them information/log level messages or something.

If you open Keychain Access.app, select the login keychain, then select "Chrome Safe Storage" in the list of application passwords (you can filter in the search box in the top right), then right click and "Get Info", what do the settings look like?

Indeed, the settings are to [Confirm before allowing access].

Hm, right, but I'd expect that if you try to use nightly/firefox to import data from Chrome, you get a prompt (or two) asking if you want to allow Firefox access to the keychain item. Does that not happen? If not, can you reproduce if you create a new user on the same mac (and a new Chrome profile with some data to import from) ?

If there's no prompt, the question will be why that is and what we can do about it on the Firefox side - it's an OS API call but perhaps we can detect this state (and I'm honestly not sure what state that is...).

To better reply, I've attached a recording with what's going on.
Initially, the first 2 errors are thrown as soon as the import window is opened.
After that, what seems to be expected follows, this being the case for 84.0a1 (2020-11-10).

(In reply to Cristian Fogel, QA [:cfogel] from comment #10)

Created attachment 9187317 [details]
Screen Recording 2020-11-12 at 10.20.11.mov

To better reply, I've attached a recording with what's going on.
Initially, the first 2 errors are thrown as soon as the import window is opened.
After that, what seems to be expected follows, this being the case for 84.0a1 (2020-11-10).

OK, but then the video stops and it doesn't show if logins then successfully imported - did they? Should we close this bug as WFM?

As spotted after some back and forth info on Slack, turns out that the main issue is the same as on bug 1582486.
Based on the suggestion, morphing this bug and adding some context to the user story.

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.