User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 When adding a Live Bookmark, or after adding one, it should be possible to edit how the feed's name appears in the Bookmark menu, in Places, and on toolbars. Reproducible: Always Steps to Reproduce: 1.Go to http://news.yahoo.com/ 2.Add Live Bookmark 3.Right-click feed, choose "Properties" Actual Results: Nothing. Expected Results: You should be able to edit the feed's name. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 ID:2006011112

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060310 Firefox/1.6a1 ID:2006031010 confirmed, the dialog doesn't pop up

Update: you should now be able to rename live bookmarks thanks to work on bug 330023; editing feed URI is still pending.

(In reply to comment #2) > Update: you should now be able to rename live bookmarks thanks to work on bug > 330023; editing feed URI is still pending. > Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060323 Firefox/1.6a1 - Build ID: 2006032310 I can rename the feed via Properties, but I have to restart the browser to see the new name.

Hass: Yes, that's bug 331154, which brettw should be landing a fix for soon. You don't have to restart the browser right now, but the change won't show up in the current window, only new ones that you open after the change.

Comment on attachment 217357 [details] [diff] [review] Allows for editing of feed & site URIs; fixes bug in livemark service when setting feed URI; fixes bug in toolbar & menu in handling livemarks with no site URI (332613) >Index: browser/base/content/browser.js >+ // Live bookmarks aren't required to have site URIs >+ if (button.getAttribute("siteURI")) { nit: if (button.hasAttribute("siteURI")) { >Index: browser/components/places/content/bookmarkProperties.js > /** >+ * This method checks the current state of the input fields in the >+ * dialog, and if any of them are in an invalid state, it will disable >+ * the submit button. This method should be called after every >+ * significant change to the input. >+ */ >+ >+ validateChanges: function BPP_validateChanges() { nit: no newline betw. comment and function. sr=ben@mozilla.org with these changes.

Landed on branch & trunk.

Could this patch be responsible for the test failures on balsa?

Um, oops. Looks like balsa has it's stuff under control. Weird.

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

Checkin for this bug may have caused a 15% increase in number of allocations on balsa. See bug 333173.

This bug has risen to be the prime suspect. Would be good to get some action on it as soon as possible so we don't have to back it out. Note that it also cased a refcount-leak increase by around 30%

I will look into this in the next 24 hours and see if I can identify anything in this patch that would cause the allocation increase.

Rolled back on branch & trunk, which did reduce RLk and A on branch balsa. OK, will test with alloc test and figure out what's going on before resubmitting.

Landed (again) on branch & trunk.

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