1822314 - `DOMException: Could not parse path (null): NS_ERROR_FILE_UNRECOGNIZED_PATH` errors in the Browser console when opening the Import Wizard window

Status: VERIFIED FIXED

(Firefox :: Migration, defect, P3)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: image.png

Found in

• 113.0a1 (20230314010803)

Affected versions

• 113.0a1 (20230314010803)
• 112.0b1

Tested platforms

• Affected platforms: Ubuntu 20.04, Windows 10x64, macOS 12
• Unaffected platforms: none

Steps to reproduce

1. Open Firefox > App Menu > History > Manage History.
2. Click on Import data and Backpup > Import Data From Another Browser.
3. Observe the browser console.

Expected result

• No errors are displayed.

Actual result

• Multiple DOMException: Could not parse path (null): NS_ERROR_FILE_UNRECOGNIZED_PATH errors.

Regression range

• Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=604ac36df40777fb5c5bd4309038955b7c672b72&tochange=45df0c21ab3161cd3b6eb6adbb2b54ef244ec65c

Additional notes

• Attached a screenshot.
• I am not aware if any functionality is affected. The import works as expected.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:axtinemvsn, since you are the author of the regressor, bug 1467094, could you take a look?

For more information, please visit auto_nag documentation.

Comment 2

[:Gijs (out for now; he/him)]

This seems to be because we now run an exists() call inside getDataPath in the Chrome Migrator Utils:

https://searchfox.org/mozilla-central/rev/47aea2f603cc18144afcedbd604a418f11e90f9b/browser/components/migration/ChromeMigrationUtils.sys.mjs#322-333

for (let subfolders of options) {
  let rootDir = subfolders[0];
  try {
    let targetPath = Services.dirsvc.get(rootDir, Ci.nsIFile).path;
    targetPath = PathUtils.join(targetPath, ...subfolders.slice(1));
    if (await IOUtils.exists(targetPath)) {
      return targetPath;
    }
  } catch (ex) {
    // The path logic here shouldn't error, so log it:
    console.error(ex);
  }

and if no extant path is found, we return null. But the caller in getSourceProfiles does not expect null:

https://searchfox.org/mozilla-central/rev/47aea2f603cc18144afcedbd604a418f11e90f9b/browser/components/migration/ChromeProfileMigrator.sys.mjs#106-109

let path = await lazy.ChromeMigrationUtils.getDataPath(
  this._chromeUserDataPathSuffix
);
let exists = await IOUtils.exists(path);

and will pass null to IOUtils.exists() which throws an error.

It would probably be sufficient to update that line to let exists = path && (await IOUtils.exists(path));

Comment 4

[portiawuu]

Attachment: Bug 1822314 - Fix NS_ERROR_FILE_UNRECOGNIZED_PATH errors when opening the migration wizard.r=mconley,kpatenio,niklas

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/120f55022ec5
Fix NS_ERROR_FILE_UNRECOGNIZED_PATH errors when opening the migration wizard.r=mconley

Comment 6

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/120f55022ec5

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:portiawuu, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox113 to wontfix.

For more information, please visit auto_nag documentation.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

This should be pretty safe for uplift if we want it, although I don't think there's any end-user benefit here. This is mainly dealing with console error spam. Would we still want it?

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Probably not, thanks.

Comment 10

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Verified fixed with Firefox 114.0a1 (2023-05-04) on Windows1 10x64, macOS 12 and Ubuntu 20.04. There DOMException: Could not parse path (null): NS_ERROR_FILE_UNRECOGNIZED_PATH errors are no longer displayed in the browser console after following the steps from comment 0.