Found in

• 117.0a1 (2023-07-23)

Affected versions

• 117.0a1 (2023-07-23)
• 116.0

Tested platforms

• Affected platforms: one Windows 10x64 machine
• Unaffected platforms: macOS 12, Ubuntu 22, other Windows 10x64 machines

Preconditions

• browser.migrate.chrome.extensions.enabled: true

Steps to reproduce

1. Open the browser console.
2. Open the migration window and observe the browser console.

Expected result

• No errors are displayed.

Actual result

• Multiple errors are displayed. Attached console error file.

Regression range

• Not a regression, happens with implementation of extensions import (bug 1836773).

Additional notes

• Attached a console error file.
• Similar to bug 1842613 and bug 1840792 that I can no longer reproduce either of them on the same station. However, I can reproduce this issue if the browser.migrate.chrome.extensions.enabled is set to true.
• I am not aware of any functionality issue and the issue is reproducible only on a Windows 10x64 machine.

Do those two Chrome profiles have any extensions installed? If not, then I think this is behaving as expected; technically we could be doing a bit nicer error reporting for this specific circumstance, but that's just cosmetic.

(In reply to Molly Howell (she/her) [:mhowell] from comment #1)

Do those two Chrome profiles have any extensions installed? If not, then I think this is behaving as expected; technically we could be doing a bit nicer error reporting for this specific circumstance, but that's just cosmetic.

It seems that the profiles folders do not exist at all for some reason inside C:\Users\user\AppData\Local\Google\Chrome\User Data and I'm assuming they don't exist in Chrome browser as well because counting the folder profiles matches the profiles displayed in Chrome browser. So they might be deleted or something along the way. I don't have steps to reproduce, unfortunately.

Hmm. So the parent of the directory we were looking in, that being the profile itself, didn't exist. That makes it sound more like we shouldn't have been trying to get into there in the first place.

Gonna turn this over to someone who actually worked on any of this stuff, I think. Mike, do you know if we have something in this migrator that could have cached Chrome profile paths, or some other way we could have gotten into a time-of-check vs. time-of-use issue here? Otherwise I'm not sure how this would have happened.

Huh. Bizarre. If the profile folders don't exist, then where is Chrome storing the profile folders? And I presume that if the profile folders don't exist, then Firefox isn't offering to import from any Chrome profiles?

If you open Chrome in one of those existing profiles and visit chrome://version/, where does the Profile Path point to?

(In reply to Mike Conley (:mconley) (:⚙️) (PTO: Aug 14-18) from comment #4)

Huh. Bizarre. If the profile folders don't exist, then where is Chrome storing the profile folders? And I presume that if the profile folders don't exist, then Firefox isn't offering to import from any Chrome profiles?

If you open Chrome in one of those existing profiles and visit chrome://version/, where does the Profile Path point to?

Hello Mike and sorry for the late response. Chrome profile Path is: C:\Users\user\AppData\Local\Google\Chrome\User Data\profile name.
I cannot open the missing profiles in Chrome because they are not displayed. I mean I have 12 profile folders and 12 profiles in Chrome. Firefox is offering to import from those 12 Chrome profiles and can import data from them. I think I found some steps at least to display extensions errors (DOMException: Could not get children of file(C:\Users\al3x_\AppData\Local\Google\Chrome\User Data\Profile 12\Extensions) because it does not exist):

1. Make a Chrome profile with some extensions.
2. Close Chrome and delete the profile contents (e.g C:\Users\user\AppData\Local\Google\Chrome\User Data\profile name).
3. Open Firefox, enable extensions (browser.migrate.chrome.extensions.enabled: true).
4. Open the migration window and observe the console.

If more information is needed please let me know.

(In reply to Molly Howell (she/her) [:mhowell] from comment #3)

Mike, do you know if we have something in this migrator that could have cached Chrome profile paths, or some other way we could have gotten into a time-of-check vs. time-of-use issue here? Otherwise I'm not sure how this would have happened.

Sounds like the Local State file, which we grab here claims this profile exists, but it does not, in fact, actually exist?

I'm actually inclined to suggest that this is the expected behaviour. The only brokenness is the fact that we report errors in devtools (not directly to the user) - but in fact, this is an error state. We shouldn't normally end up in the situation where the Local State file claims the profile exist, but it is actually missing on disk.

I'll mark this as S4 for now and ask Mike to confirm as WORKSFORME/INVALID when he's back from PTO. :-)

Thank you! I want to point out one more thing I missed adding in the initial description (sorry for that). The load time of the migration window is increased a little due to errors (similar to bug 1840792 ). This happens only the first time the migration window is opened, or after the about:preferences page is closed and reopened and the migration window is opened again.