The Rename button on the Bookmarks toolbar appears to do the same thing as the Properties button (opens the bookmark properties window). Perhaps it should be removed?

The rename item exists because inline the renaming was temporarily removed. Adding bug 114431 as a dependency. If that bug gets resolved as WONTFIX, then this item should be removed. If that functionality returns, then this bug should get closed as INVALID.

Perhaps i don't correctly understand the inline-renaming feature you are describing, but it seems to me that inline renaming would be another argument *for* getting rid of the "Rename" button. If you can edit bookmarks inline, why reach up to the toolbar and click the "Rename" toolbar button instead of just clicking on the bookmark you want to edit? I can see why you might want a Rename menu item, but the Rename toolbar button seems useless to me, especially if you have inline renaming.

Adding "context menu" to summary. To James: inline renaming was a buggy feature with which you were able to initiate renaming by single clicking on the bookmark.

The rename option also appears in the context menu. This is really bad UI since we have the same option with different names twice in the toolbar and in the context menu. It doesn't seem to be a risky or difficult change for 1.4 but it would simplify the Bookmark manager UI noticeably, BTW, this Rename option isn't even mentioned in the HELP files, the Help siles say that renaming a bookmark is done via the properties button.

mozilla1.4 shipped. unsetting blocking1.4 request.

it doesn't look like bug 114431 is going to get fixed for 1.5 final, so we should remove this menu item/button once we are on a branch. Gerv

This patch removes "Rename" from toolbar and context menu. Gerv

Comment on attachment 130965 [details] [diff] [review] Patch v.1 Requesting review from ben. Gerv

Taking bug. Gerv

This seems to be a low-risk fix - any chance of it getting into 1.6 final?

Sorry for the spam. Bringing this bug to everyone's attention again. Patch for this bug seems to exist and it seems to be low-risk. Any chance of making it into 1.8a3?

1.8a3 is out. Nominating for 1.8a4.

1.8a6 is out, nominating for 1.8b

Hmm, does the patch still apply?

patching file xpfe/components/bookmarks/resources/locale/en-US/bookmarks.dtd Hunk #1 succeeded at 65 with fuzz 2 (offset 17 lines). patching file xpfe/components/bookmarks/resources/locale/en-US/bookmarks.properties Hunk #1 succeeded at 45 (offset 7 lines). patching file xpfe/components/bookmarks/resources/bookmarksManager.xul Hunk #1 succeeded at 269 (offset 18 lines). patching file xpfe/components/bookmarks/resources/bookmarks.js Hunk #1 FAILED at 291. Hunk #2 succeeded at 788 (offset 16 lines). Hunk #3 succeeded at 850 with fuzz 2 (offset 1 line). Hunk #4 succeeded at 918 (offset 16 lines). Hunk #5 succeeded at 957 (offset 1 line). 1 out of 5 hunks FAILED -- saving rejects to file xpfe/components/bookmarks/resources/bookmarks.js.rej patching file xpfe/components/bookmarks/resources/bookmarksOverlay.xul Hunk #1 succeeded at 65 (offset 16 lines). Seems not...

Feel free to trunce it... ;)

Reassigning as per Bug #32644

WORKSFORME Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2pre) Gecko/20110520 Firefox/4.0.2pre SeaMonkey/2.1.1pre

Comment on attachment 176292 [details] [diff] [review] Oops, forgot a bit... ...canceling stale review.