Encountered a fairly major dataloss bug with the bookmark organizer. Steps to reproduce: 1. Create a bookmark with a tag 2. Open the Bookmark Organizer 3. Expand tags folder 4. Select the tag in the left-hand pane 4. Select the bookmark in the right-hand pane 5. Notice that the "Name" field in the bottom-right pane is blank (where the bookmark title should be) 6. Click in the blank Name field 7. Click again on the bookmark in the top-right pane 8. Watch the bookmark name vanish, never to return Build ID: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008030111 Minefield/3.0b4pre

I see this also on Windows XP.

Possibly related to bug 419731?

(In reply to comment #2) > Possibly related to bug 419731? that is a view problem, while here is a content problem, imho bookmarks inside tag folders should not be editable at all (for the easy fact that we cannot know which of all bookmarks have generated that child into the tag). Suppose that you have the same bookmark in the menu with a title and on the toolbar without a title, you tag one of them, you have a new element in tags binded to that url, but you cannot know if the user has tagged item in menu or in toolbar. So what will you edit?

see onNamePickerChange

Comment on attachment 309364 [details] [diff] [review] patch r=me.

mozilla/browser/components/places/content/editBookmarkOverlay.js 1.38

Asaf, this bug isn't fully fixed => Reopen. It tried it with the latest builds under WinXP and OS X. This problem still appears if you have a tag set before your patch went in. It sounds crazy that it will show such a behavior but this is what I can see here: STR: 1. Select an old tag and a bookmark inside => name field is blank 2. Add a new tag to this bookmark 3. Select this new tag and the contained bookmark => The name field shows the real name of the bookmark. I'll attach a copy of my testing places.sqlite which shows this issue for the tag test and speedtest.net.

I have to add that the dataloss doesn't happen anymore. But the bookmarks name is still not displayed in the details deck.

We cannot fix this for item which were already affected by this bug. What happened before this patch went in is that we were setting the title to "" once you tabbed to the empty name field. Now, if you tag the bookmark another name, a new item is created under the new container for that tag (and again, the history title is taken as its title).

Ok, then I can verify this bug with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008031504 Minefield/3.0b5pre ID:2008031504 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031506 Minefield/3.0b5pre ID:2008031506

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv