User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8 In the Bookmarks Manager window, when a previously empty bookmark folder is made non-empty (e.g., by dragging something into it), its icon does not switch from the empty-folder icon (with no plus or minus box to the left) to either of the non-empty-folder icons (with a plus or a minus box to the left). Opening or closing the folder does not cause the icon to switch. Only closing and re-opening a parent or ancestor folder seems to refresh the icon to match the folder state (non-empty). This is a dataloss bug because the use might delete the folder thinking that he or she is deleting only the folder itself, while actually deleting any number of bookmarks, etc., in that folder. Reproducible: Always Steps to Reproduce: 1. In the Bookmark Manager window, within some bookmark folder, ... 2. Create a new folder (do New Folder); call it A. 3. Note that for that new, empty folder the UI uses its normal representation of an empty folder (without any square containing a "+" or a "-"). 4. Create a second new folder; call it B. 5. Put B in A (drag B's icon onto A). 6. Close and re-open the parent folder. Actual Results: 5.5 Notice that UI still uses the representation of an empty folder (without any square containing a "+" or a "-"). 6.5 Notice that only now does the UI switch to the representation of a non-empty folder (with a square containing a "+" or a "-"). Expected Results: 5.5 The UI should use the representation of a non-empty folder (with a square containing a "+" or a "-").

This is true for SM 2.0, but it's unlikely that it will be fixed there (the affected code is complex, and the 2.0 branch only receives security fixes and very safe ones). However it's fixed on trunk (SM 2.1 pre-releases). Marking WFM.

(In reply to comment #1) > This is true for SM 2.0, but it's unlikely that it will be fixed there (the > affected code is complex, and the 2.0 branch only receives security fixes and > very safe ones). However it's fixed on trunk (SM 2.1 pre-releases). Marking > WFM. If you see that the bug exists in SM 2.0, how WFM be appropriate? (Isn't "works for me" for when a bug can't be reproduced?) Isn't there any category that means "fixed"? (Or is something like "fixed" reserved for explicitly known bug fixes, rather than apparently and/or accidental fixes? Daniel

(In reply to comment #4) > If you see that the bug exists in SM 2.0, how WFM be appropriate? > (Isn't "works for me" for when a bug can't be reproduced?) Yes, and I explained that it cannot be reproduced with SM 2.1 pre-releases anymore. Version still says 2.0, since that's where it was seen, but as I said it won't be fixed there, so there's no point in keeping this bug open if it is fixed for the next major release. > Isn't there any category that means "fixed"? Yes there is, RESO/VERIFIED FIXED (when an attachment on the bug was checked in and fixed the bug) and RESO DUPLICATE (if the above applies to the other bug) > (Or is something like "fixed" reserved for explicitly known bug fixes, > rather than apparently and/or accidental fixes? Exactly, FIXED means we know which change fixed it. Here I don't, but I know it's not happening anymore, so WFM. If someone takes the time to find out what fixed it, it could be changed to RESO DUPLICATE.