could be what has been imported is bookmarks.html (an old version of your bookmarks).
you could try to restore bookmarks from a JSON backup (Restore functionality is in the Library reachable through Organize Bookmarks)

Yes, 3.0 is not correctly flipping the pref to false once used, and on upgrade that causes 3.5 to import bookmarks.html because the pref says to do so. we could investigate a fix for 3.0.14/15, i just fear about possible regressions since that pref is used differently on 1.9.0 branch.

> since that pref is used differently on 1.9.0 branch.
Always a dangerous thing!
> if a certain combination of prefs exists we hit this.
What combination? How common is that combination? Is it something that depends on a user explicitly changing a setting somewhere, or are they settings we automatically change to store some kind of state?

I noticed that status1.9.1 is set to "unaffected" but there's no explanation in the bug. A firefox 3.5 user can't get into the same combination as a 1.9.0 user and hit this problem with an eventual upgrade to 3.next?

Dan: I set that per Marco. The issue is only present on 1.9.0 because of how it sets that pref. The only place this would need to land is on the 1.9.0 branch.
We really need some more details here, especially if we should consider blocking on this bug and respinning. Dan's comment 15 is a good start...
Also: Is it clear that this scenario is the only or majority one that causes users upgrading from 3.0 to 3.5 to "lose" some of their bookmarks? Are there others?

We discussed this on IRC, sorry for not coming back with information.
The known affected scenario are users who have hit a places.sqlite corruption in 3.0.x, their db has been restored but the pref has not been flipped off. On upgrade to 3.5 it will read the pref to true and import bookmarks from bookmarks.html.
3.5 is unaffected because the prefs are correctly flipped off once used. We cannot take the patch that is on 3.5 on 3.0 because it also requires backend changes in Places initialization, that is somehow risky. That's why i provided a 3.0 only change that is a partial part of that patch (for reference it is bug 462366) and should be safe.
There is a workaround, known to support, that is to restore a JSON backup.
(In reply to comment #17)
> Also: Is it clear that this scenario is the only or majority one that causes
> users upgrading from 3.0 to 3.5 to "lose" some of their bookmarks? Are there
> others?
Some kind of corruption of the db could cause loss, but that's unpredictable andwe handle them replacing the db. There are not other known causes that can be fixed atm.

PS: by "pref is used differently" i meant the pref was acting wrongly in 3.0, causing looping bookmarks restores, and we fixed it in 3.5 so that it just does what it says: imports bookmarks.html and gets flipped back.

(In reply to comment #20)
> Can we get clear reproduction steps to cause this issue, please?
since causing a db corruption is not so easy, you could just:
- create a new profile
- add a bookmark in the toolbar
- close the browser and ensure you have at least one json backup in bookmarksBackup profile dir
- open browser and set importBookmarksHTML to true (this is one of the things that happen when the db is found corrupt in 3.0)
- restart browser, check that importBookmarksHTML is still true
- check for updates and install 3.5.2
- check bookmarks.html has been imported
- check importBookmarksHTML has been flipped to false
If you need steps that a user could run into, we'll need to provide a corrupt DB.

Comment on attachment 396559[details][diff][review]
patch v1.0
We're going to block on this for 1.9.0.14. This needs to land on CVS HEAD and on GECKO190_20090812_RELBRANCH.
Approved for 1.9.0.14 and 1.9.0.15. a=ss for release-drivers

I recently reported this bug after it happened to me when I upgraded from 3.x to 3.5.2, so how can it be listed as RESOLVED FIXED as a 1.9.0-only issue? I've been running Firefox since version 0.9 and this bug has never happened before--my bookmarks were always carried forward to the latest version with each upgrade.

hnorthrup@yahoo.com: This bug only happens on migration from 3.0.x to 3.5.x. The fix happened on the 3.0.x side (since it was a problem there). This bug has been fixed and we will push the fix in Firefox 3.0.14 so users upgrading from that to 3.5.x will no longer see it.