User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061005 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061005 Minefield/3.0a1 Latest Firefox 2.0 Branch, clean profile. Reproducible: Always Steps to Reproduce: 1. In IE 7.0 RC1 visit http://bugzilla.mozilla.org/, login to Bugzilla and confirm that you want to save password. Next close IE. 2. Start Firefox, in main menu choose File -> Import and try to do import. 3. Passwords don't import. In Error Console: Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: XStringBundle :: getString :: line 17" data: no] Source File: XStringBundle Line: 17

Does not work in IE 7 release. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.2) Gecko/20070208 Firefox/2.0.0.2 No chrome package registered for chrome://navigator/locale/navigator.properties . No chrome package registered for chrome://navigator-region/locale/region.properties . No chrome package registered for chrome://communicator-region/locale/region.properties . is what I get in the error console.

Not blocking the release, but would be nice should someone fix it. Would need a baked trunk fix first.

FYI: Passwords will not migrate from IE 6 to Minefield 2007070604 (latest nightly).

IE7 Migration -> jmathies

IE7 now stores it's password and form filling data in the DPAPI (Data Protection Application Programming Interface) and uses the URL of the page the form was located on as the encryption key in protecting the password. The same process is used in form autofill information. Apparently the URL is then discarded, making it impossible to decrypt the data until the user revisits the page. At this point I'm not seeing a way to address this, but I'm just getting into the research of it. Will post back with what I find.

Just a note, I still need to investigate any IE6 issues, which should be working using the older PStore methods, which was the original target of this bug.

Latest nightly with IE6 - passwords imported. (re: comment #4).

Here are some references - Recovering Internet Explorer 7 Passwords http://www.passcape.com/recovering_ie7_passwords.htm IE PassView methodology http://www.nirsoft.net/utils/internet_explorer_password.html

Are there any follow up bugs on removing the items Firefox cannot import from the File -> import dialog?

Added - bug 399206.

not going to fix on 1.8 branch if there's no plan to fix in future versions.

verified.

I believe this should be documented somewhere official. It's better to point to SUMO for support questions. Please also see bug 399206.

(In reply to comment #15) > I believe this should be documented somewhere official. It's better to point to > SUMO for support questions. Please also see bug 399206. http://support.mozilla.com/en-US/kb/Importing+bookmarks+and+other+data+from+Internet+Explorer "Note that you cannot import passwords from Internet Explorer 7 or higher as passwords in Internet Explorer 7 are saved in a new format that is nearly impossible for external programs to extract data from."

Ok, moving it over to bug 381459 which is the tracking bug for all the issues.

Google did something interesting with this, they do real-time lookups into the ie store as users visit sites (the uri is a decryption key) and migrate if data is found and decrypted successfully. If the overhead isn't too bad (maybe we can get a copy of the site list to key off of?) we might try something like this. It doesn't fit with our current all-or-nothing approach, but if users find it useful we might consider it.

filed bug 538654