User-Agent: Mozilla/5.0 (X11; U; Linux i686; eo; rv:1.9.3a6pre) Gecko/20100622 SeaMonkey/2.1a2pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; eo; rv:1.9.3a6pre) Gecko/20100622 SeaMonkey/2.1a2pre I have as hard of a time believing this bug hasn't been reported (I searched but found no results, but eh, it's usual for my searches not to turn up anything but the report to be marked a duplicate) as I do believing that this is intentional. When you move a bookmark to a different location in the same folder or delete a bookmark from the folder, the object count indicated in the Bookmark Manager is wrong (incrementing one when moving and not decrementing when deleting). Reproducible: Always Steps to Reproduce: 1.Create a new bookmark folder. 2. Add a bookmark to it. 3. Add another bookmark to it. 4. Move the second bookmark above the first. 5. Move the second bookmark back to its original position. 6. Delete the bookmarks, but not the folder. 7. Open up the Bookmark Manager. 8. Select your created folder in step 1. 9. Look at the status bar. Actual Results: I see: 4 object(s) Expected Results: I should see: 0 object(s) This has affected SeaMonkey for a long time, up to the latest trunk nightlies. It occurs with the default theme, as well as with Modern, which is what I normally use. Restarting the browser shows the correct count in all bookmark folders, but the number gets wrong when you start moving or deleting bookmarks again.

Will probably be fixed with Bug 498596 - (SMPlacesBMarks) Switch SeaMonkey bookmarks to places backend.

Well, the problem is: The new Bookmarks Manager has no status bar anymore, so there is no count that could be compared. So unless this had any other effects, this bug is WORKSFORME or INVALID on trunk and alpha 3, and the 2.0 branch will surely not be fixed. Additionally I'd say it's quite unlikely that the new back-end (Places) would count incorrectly internally, given how many tests the FF guys wrote for it.

Keith, please try to reproduce with a current SM 2.1 trunk nightly, or SM 2.1b1.

Well, it seems to not affect 2.1a3+, since the migration to places (in fact, I can't see how it's the least bit different than Firefox's bookmark manager, warts and all). I do, however, think it's a bit mean to mark this as WORKSFORME (or INVALID), as it was a valid bug when I reported it.

Unfortuntely the only RESOLVED options are: FIXED INVALID WONTFIX DUPLICATE WORKSFORME INCOMPLETE Which would you suggest? I think WONTFIX is the most appropriate since nobody still around understands the old html/rdf bookmarks code - The main reason for switching to the Places backend.

(In reply to comment #4) > Well, it seems to not affect 2.1a3+, since the migration to places Resolving WFM as per that. > I do, however, think it's a bit mean to mark this as > WORKSFORME (or INVALID), as it was a valid bug when I reported it. This is not about being mean (there's no such intention here!), this is about triage (sorting bugs into categories where something needs to be done for future versions or not). The status/resolution names may be inappropriate sometimes, but that's what we have (see comment 5). And in this case I think WFM applies because the issue cannot be observed anymore. The reasons don't really matter, or whether the bug originally really existed or not: It won't be fixed in any of the earlier versions anyway. What counts is the trunk, and that is not affected, so WFM it is. Please only reopen if you can see the very same issue with trunk (unlikely). Thanks for reporting this, though. You may rest assured that if it was still visible with trunk, we would not have just closed this. There's just no point keeping something open that will never be actioned upon.

Hm, it seems to me that the bug was fixed by moving from the HTML/RDF code to SQLite and the fix just won't be backported, but I'm not going to quibble about semantics.