This is a regression to an earlier problem which I thought was fixed around 0.95 or 0.96 ... If I delete "Imported IE Favorites" from my bookmarks, it stays deleted only until I quit and restart Mozilla, and then it's back. Every single damn time. I've never been wild about the automatic importation of bookmarks from That Other Browser to begin with, but this is really offensive. I'd happily forget that IE existed at all if I didn't have to check the pages I develop in it; I certainly don't want to be reminded of it every time I start up a browser I actually like. Build info: Mozilla 0.9.8+ Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020222

wfm - but i'm using winnt, and an old build: 20020204 (0.98 release). this was supposedly fixed sometime ago (bug 22642) and bug 84272 was filed later so that we have better control over this using ui. ... perhaps this is a regression (on mac only) as mentioned in 22642

Not on Mac only. I just upgraded to build 2002022203 on Win98, and saw these in my bookmarks. I got rid of them long ago... Confirming All/All and adding regression keyword.

Mozilla 0.9.8+ Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8+) Gecko/20020226 I have the same problem. Plus I can't even delete the extra ones, for my managing bookmarks doesn't work :(

*** Bug 130786 has been marked as a duplicate of this bug. ***

I have the same problem with 0.9.9 on Win2K, which I did not have with previous versions such as 0.9.8. I concur with Daniel, this is very annoying.

*** Bug 132185 has been marked as a duplicate of this bug. ***

*** Bug 132523 has been marked as a duplicate of this bug. ***

*** Bug 133592 has been marked as a duplicate of this bug. ***

Isn't this bug the exact *opposite* of bug 134535? I *dream* of my IE Favorites coming back! They got corrupted by bug 130079, and I finally deleted the imported folder (never to see it again). I tried creating a new profile and it didn't recreate the link either. Rather than relying on the user to delete the imported folder -- and on Mozilla to interpret the user's intentions -- there really seems a need for an "Import IE Favorites?" control.

What happens if you manually edit your PREFS.JS (to never re-import) by adding: user_pref("browser.bookmarks.import_system_favorites", false); (Before editing it, you need to exit Mozilla, including the Quicklaunch.) I mention it because there was an early reference to bug 84272 (add UI control for import preference) but no one since has mentioned whether or not they were testing this preference/control. If this works for y'all, then this bug should be RESOLVED and you might want to transfer your votes to bug 84272. Otherwise, the Summary might need to be clarified to mention that the preference doesn't work anymore.

The last comment on this bug dates from April of 2002. I note that this behavior occurs on the 1.3 beta I am using, build 2003030305. I do not want Favorites imported, as I use Mozilla as my primary browser, and periodically export its bookmarks to Favorites for the occasional times I must use IE. Therefore the automatic import of Favorites effectively doubles the size of my bookmarks.html file. There should at least be a user option to turn this off.

Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

SM 2.0.1