When a user chooses to "File a Bookmark", he is given the option to specifiy/modify the URL, specify/modify the name for the bookmark, and specify/modify under which directory it should be filed. But when a user goes into the bookmark manager, right-clicks a bookmark, and chooses Properties, he is offered Bookmark, Name, Keyword and Comments entry fields under the Info tab. It is inconvenient for a user to have to go into the bookmark manager every time he wants to associate a keyword with, or add some comments about, a website. A user should be allowed to enter all relevant information about a bookmark the first time he files it. Namely, the Add Bookmark dialog box (that comes up when a user chooses Bookmarks / File Bookmark) should have the Keyword and Comments entry fields in addition to all the others.

This is not the same as bug 82721, which deals with an underlying API. It is presumably blocked by that, though. Clarifying the summary, marking NEW.

arg. i'm still opposed to this. The file bookmark dialog is for _filing_ a bookmark, not creating one. if you want to create a bookmark then you should use the bookmarks window, pick where you want to put the bookmark, select new bookmark and use that dialog. If you need a url, you can copy it or drag and drop it.

Um, not quite. When you use the File Bookmark dialog, you're creating a bookmark. Note that it was once called "Add Bookmark As...", but only the wording -- not the dialog -- changed.

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

the suggestion from the dupe was to use a button (maybe just a triangle) to show/hide the extra properties. I concur. This widget would then of course remember state and be unobtrusive for those who don't use it and a godsend for those of us tired of having to fire up the manager to add in properties for a bookmark they just _created_. Also, this would be great eyeballs for custom keywords - my favorite underpublicized feature.

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

Nah. You don't typically want to create these entries for all bookmarks, so adding fields to this dialog is just adding clutter.

Why shouldn't I "typically want to create the entries"? Especially comment or keywords are important exactly when I _create_ the bookmark!!! Why should we force all users, who don't want to classify their bookmarks 2 or 3 days later, to first "file" the bookmark and then to go to the bookmark-manager and search their new bookmark and then right click the bookmark and then - finally - allow them to enter their comments and keywords??? From the users point of view this behaviour is not really user-friendly - it's time-consuming! Also the hint "if you want to add a bookmark then use the bookmark-window" is not very useful because the proposed way needs 5 (five!) clicks to add a new bookmark - and then the user still has not been allowed to add comments or keywords to the bookmark... Once again: we should provide two ways to add bookmarks 1) like before a one or two-click solution to simply append a bookmark to the bookmark-list (perhaps one can allow in the preferences for a default-folder where "Add Bookmark" appends the new url) 2) a solution where the user can specify the folder the new bookmark should be added - including all relevant properties related to bookmarks which the user might want to enter - and comments or keywords are such relevant properties - of course _not_ for all users - but even if only 10% uses this feature we should provide them with an "easy to use"-solution...

I'm reopening this bug. Ben, I really think you should reconsider this. Bookmark keywords is one of the coolest features of Mozilla, but having to *first* file the bookmark and *then* opening another dialog to add the keyword - that's terrible!

I forgot to say that this has been requested in netscape.public.mozilla.wishlist several times.

jonas thanks! This somehow got resolved as wontfix when I wasn't looking. It is my professional opinion that Ben is just wrong :-). I want a disclosure triangle. I want it defaulted open, and I want it to remember state.

OK. Fair enough.

mass reassign of pchen bookmark bugs to ben

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

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

Any activity here? This bug hasn't been active in a long time and I think it is really important.

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

putting on radar for point release.

His would be a nice advertizement for "keywords" - once people see it, they'll want it (BAD). I miss having the option of adding a KW and comment *very* often.

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

If you add URLs to dmoz.org, the spider grabs the description from the meta tag. It would be very nice if mozilla also prefilled the description field from the meta tags if one chooses "File Bookmark...".

Jens: If you're interested in that, file a new request for enhancement. Your suggestion has nothing to do with this one.

Has there been any recent activity on this ? The target milestone is showing as 1.2 alpha, but I'm using 1.2a (2002091014) and the rfe has not been implemented.

The lack of this feature was just criticised in PC Pro (UK) magazine (sorry, not available online yet). Bad publicity in a piece that was otherwise quite positive about Mozilla's bookmark manager and search features. Here is the quote: "Unfortunately, to make searching work properly, [Moz] still requires a convoluted process of entering the necessary information when adding a bookmark in the first place. The process involves dragging the URL to a location or using a Ctrl-D shortcut, which adds the URL only and doesn't tag it properly with the kind of metadata needed to make searching effective. To do that you need to right-click the entry and enter its Properties dialog. Okay, it's not the end of the world, but it does add an unnecessary set of steps to the bookmarking process, all too often leading to an unsorted jumble." (PC Pro magazine no 101, cover date March 2003). So he hasn't noticed "File bookmark", but the same two-step process would apply even if he had. Please fix this.

The target milestone was missed long ago. Nominating for nsbeta1. Bug 99860 is scheduled for 1.4alpha, would be nice if this one could go with it.

Nav triage team: nsbeta1-

After the checkin of the big patch of bug 196756, the File Bookmark dialog now has a Keyword field. The Description field is still missing, but since the blocking bug is fixed, adding this should be next to trivial. (I'm not implying anything by that statement - this is just a status report.)

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

Here's a patch that adds the Description field into the File Bookmark dialog. I did attempt to make the Keywords and Description show by clicking on a disclosure triangle as comment 11 requests, but I just couldn't find out how to do it. I also didn't find any place in Mozilla that uses such a thing, so I had nowhere to copy from.

Comment on attachment 136137 [details] [diff] [review] patch to add description field Requesting r&sr. BTW, this also fixes bug 226002.

Comment on attachment 136137 [details] [diff] [review] patch to add description field >+<!ENTITY description.label "Description:"> >+<!ENTITY description.accesskey "E"> > <!ENTITY newFolder.label "New Folder..."> >-<!ENTITY newFolder.accesskey "w"> >+<!ENTITY newFolder.accesskey "W"> Better use the case of the letter the accesskey should match. Otherwise the respective string is scanned for the desired letter two times. See http://www.mozilla.org/projects/ui/accessibility/accesskey.html The first point of the section "How do I pick an accesskey letter?".

Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com

(In reply to comment #30) > (From update of attachment 136137 [details] [diff] [review]) > Requesting r&sr. > BTW, this also fixes bug 226002. Please look bug #226002 has been marked as duplicate of the bug #228762 which was fixed. So patch in attachment 136137 [details] [diff] [review] is obsolete now, you should create new (just remove one fix in xpfe/components/bookmarks/resources/addBookmark.xul - <label value="&shortcutURL.label;" accesskey="&shortcutURL.accesskey;" control="shortcutURL"/> + <label value="&shortcutURL.label;" accesskey="&shortcutURL.accesskey;" control="shortcutUrl"/> )

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

(In reply to comment #34) > Created an attachment (id=143926) [edit] > updated patch patch waiting for review

Comment on attachment 143926 [details] [diff] [review] updated patch >+ gFld_Description.disabled = gCB_AddGroup.checked; This line prevents you from actually entering a description for the bookmark group. r=me with it removed. >+<!ENTITY description.label "Description:"> >+<!ENTITY description.accesskey "e"> > <!ENTITY destination.label "Destination:"> > <!ENTITY destination.accesskey "D"> Odd that we don't actually use that D access key... maybe we should use it for description as nobody will be expecting it to access the destination anyway.

I'm afraid that I won't be able to spend any time in the foreseeable future updating the patch, un-bitrotting it and chasing someone to actually check it in. If anyone's interested, please feel free to take over.

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

The lack of this is very obvious in FF 3.0b1. The fact that the main bookmark dialog doesn't include all the necessary fields means that bookmarks in the "All Bookmarks" folder aren't useful, since they can't easily be maintained any other way.

Jag, ping ?

Fixed in: Bug 586947 - Places File Bookmark (Ctrl+D) needs improvement badly

(In reply to comment #42) > Fixed in: > Bug 586947 - Places File Bookmark (Ctrl+D) needs improvement badly No it's not fied. Latest comment on that in bug 586947: (In reply to bug 586947, comment 44) > > Description and keyword fields are missing. > Lets get this bug landed and decide on those fields in a followup bug. Neil has > enough problems reviewing the current patches. Please REOPEN