Critical bug in Firefox Local Backup feature: Infinite profile creation loop and extraction failure on a fresh OS installation

Hello, I am writing to report a critical flaw in the new Firefox Local Backup mechanism (HTML-based container). After formatting my PC and installing a fresh copy of Windows 10/11, I attempted to restore my 10 years of browser history using a valid backup file (.html, ~102 MB) created by Firefox 153.0.4. Although the password was correct (the UI immediately rejected incorrect ones), the restore process completely failed and entered a destructive loop. Instead of extracting the data, Firefox started infinitely creating hundreds of empty profile folders in %AppData%\Roaming\Mozilla\Firefox\Profiles without throwing a visible error to the user, completely messing up the profiles.ini file. '''What had to be done to recover the data:''' Since standard unarchivers (7-Zip) and tools like Windows certutil couldn’t parse the hybrid HTML/Base64 container, we had to reverse-engineer the recovery process using the internal Firefox source modules (PreferencesBackupResource.sys.mjs and SessionStoreBackupResource.sys.mjs from omni.ja). We had to write a custom Node.js script to: # 1 Parse the specific block-by-block Base64 encoding used by Mozilla inside the HTML wrapper. # 2 Manually decrypt the raw binary data using the backup password. # 3 Extract places.sqlite, logins.json, key4.db, and sessionstore.jsonlz4 manually. # 4 Manually inject these files into a freshly registered profile. '''The Bug Core:''' The built-in extractor in Firefox fails on fresh OS/browser installations due to path/profile synchronization errors, causing a crash loop that generates endless ghost profiles. Please review the block-by-block extraction logic and add strict exception handling to the Local Backup UI so it doesn't break the profile directory when a routine error occurs. Thank you.