Editing tags/keywords in bookmarks

I realized this is better presented as an enhancement bug. Retitling to suit.

No change as of 1.6.

Cross-references for integrating autocomplete and bookmarks:

Include in the Autocomplete list ...

Bug 101642 - Bookmark URLs, and list them on top
Bug 117967 - Bookmark names/titles
Bug 155320 - Bookmarks user clicks on
Bug 212605 - Bookmark Keywords, and don't prepend previously
      typed keywords with 'http://'

Confirming.

Hardware: PC -> All

Please implement this easy, but useful feature. Also, please display on the right side description of keyword in the address bar.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

Currently the only way to assign bookmark keywords is to add a bookmark (CNTL-D), go into the bookmark manager, find the bookmark you JUST ADDED, click on 'Properties', then click the 'More' button, and finally enter your keyword.

You should be able to assign keywords directly from the quick add dialog. It is a very small dialog already, so I can't imagine size is an issue.

I really like all the work that has been done on bookmarks in this release (Firefox 3, Beta 1) but why, oh why are bookmark keywords so shunned! They're an awesome feature, but hardly anybody knows about them because you don't even see them unless you venture into bookmark manager.

Reproducible: Always

Steps to Reproduce:
1. Go to a website
2. Add a bookmark (CNTRL-D)
3. There is no way to assign a keyword from the dialog
Actual Results:
Added a bookmark without any keyword

Expected Results:
I expect the keyword field to be on the dialog

Proof of fans of this feature: http://lifehacker.com/software/bookmarks/hack-attack-firefox-and-the-art-of-keyword-bookmarking-196779.php

Also, I believe keyword autocomplete (https://bugzilla.mozilla.org/show_bug.cgi?id=212605) should be a very nice addition to fixing this bug.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010705 Minefield/3.0b3pre ID:2008010705

When you want to modify the bookmark properties within the bookmarks sidebar you are not able to add/remove tags because no UI exists yet. Fields (like the details deck inside the Library) should be added to be able to modify the tags for that bookmark.

This also applies for bookmarks on the bookmarks toolbar.

As far as I know this has been implemented in Firefox 3.0 Beta 2. I don't know what version of Firefox you are using but in mine I am able to tag bookmarks and then search using those tags. This works with the toolbar too.

RESOLVED?

This bug isn't solved yet. The Bookmark Properties dialog still lacks the tagging UI. No idea about what specific bookmarks properties you are talking about but doing the steps from my initially comment should show this for you.

Can't find a good dupe for lack of keywords in new star Bookmark Dialog, marking NEW and duping newer bug to this. Not sure how much love this is gonna get, though - that would be a big change this late in the game, but I agree that it is troublesome and user-unfriendly.

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

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

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

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

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

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

Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.

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

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

I think there are 3 options to solve this. When clicking on Properties in the context menu in the Bookmarks sidebar:
1. Open the Library with the bookmark in question selected.
2. Open the star/"Edit this bookmark" dialog that drops down from the
AwsomeBar.
3. Just include tags in the bookmark Properties modal.

Considering that the main menu Bookmarks > Bookmark This Page does 2 (above) that seems like a nice solution. But since the Bookmarks sidebar is in a sense a light version of the Library, 1 (above) makes more sense. 3 (above), I think is the worst solution since there really is no need for a third way to edit a bookmark.

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

I wrote a mall extension which open "Edit This Bookmark" solution of No.2(Comment #12)
https://addons.mozilla.org/ja/firefox/addon/7396

s/mall/small/

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

mconnor, which plans are out there for the old bookmarks properties dialog? Should it be replaced by the page bookmarked panel like it was done by Alice's extension?

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

(In reply to comment #16)
> mconnor, which plans are out there for the old bookmarks properties dialog?
> Should it be replaced by the page bookmarked panel like it was done by Alice's
> extension?
>

Yes, it should. Making this bug target 3.1.

Fixed by the Ex Bookmark Properties addon.

See also bug 426674

oops, forgot link:

Ex Bookmark Properties Addon:

https://addons.mozilla.org/en-US/firefox/addon/7396

Created an attachment (id=325882)
Adds tagging to Bookmark Properties dialog

I've made a patch to add a tag field into the Bookmark Properties dialog. The functionality was taken from the new add/edit bookmark overlay attached to the Location Bar.

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

In support of this enhancement: When I type a bookmark keyword [not tag] into location bar, then press enter, the URL of that keyword bookmark will definitely be loaded. It is weird that the actual URL about to be loaded is NOT shown in location bar dropdown list. But it's not the only thing that is not shown in the awesome bar dropdown though it should be... (bug 424797). The latter bug prevents effective use of the workaround for this bug 212605, namely that you can include the keyword in the title of your bookmark (e.g. "[wp] wikipedia quicksearch").

Andrew, i tested your patch with Minefield/3.1b1pre ID:20080902033133 and it seems to be okay (tag creation, deletion). you may want to ask for (ui-)review ?!?

(From update of attachment 325882)
Thanks, XtC4Uall. I've added the reviewers based on mconnor's suggestion from #developers.

Thanks for the patch Andrew, but I don't think we should be extending that dialog. Instead, we should be standardizing on the new bookmark properties panel, and removing the old one.

I think that the dialog should embed the new panel, like the library does. This will reduce code and provide a consistent experience for users.

I also don't like that there are two versions of bookmark properties UI available via primary UI that are so radically different in appearance, but that's an issue for another bug.

(In reply to comment #25)
> ... we should be standardizing on the new bookmark properties
> panel, and removing the old one.

> I think that the dialog should embed the new panel, like the library does.

anyone mind enlighten me about the "new" bookmark properties panel (mockup, bugreport, etc.)?

> I also don't like that there are two versions of bookmark properties UI
> available via primary UI that are so radically different in appearance, but
> that's an issue for another bug.

are there any bulletproof plans in 3.1 timeframe for this?
if not, i'd say get this in before there's nothing at all.

(In reply to comment #27)
> > How are 3 and 13 instant apply if they don't have a folder name yet?
>
> Items I create using 3 don't seem to show up until I click "Add", fwiw. Or is
> that part of the change you're making? It's important that in those cases
> "Cancel" means "don't actually create the thing" as opposed to "don't rename
> the thing from the default name to what I just said".

It should appear as New Folder, and if you click Cancel it should disappear. It's working like that for me.

(From update of attachment 345470)
ui-r+ with the following nit/change as per localizer comments:

+dialogAcceptLabelAddLivemark=Subscribe
+dialogTitleAddLivemark=Subscribe with Live Bookmark

Quite right that you don't subscribe to the Live Bookmark; you subscribe to the feed WITH a Live Bookmark. Alex's design was right, though, to carry the verb that we use elsewhere in the UI forward into this dialog, though.

Created an attachment (id=345631)
followup

Followup to fix locale as required in previous comment by Beltzner, accesskey for New Folder is o per IRC.

followup pushed:
http://hg.mozilla.org/mozilla-central/rev/1ed0ef198437

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

verified in nightly build of 2008103102 on Mac

also updated litmus test case: https://litmus.mozilla.org/show_test.cgi?id=5952

Doing the string change without a key change is borderline. You may read the original string as obviously broken or not, and either localizers would catch that magically or not.

Mind doing a quick post to mozilla.dev.l10n to make sure that localizers see that there is an update to an existing string,

-dialogTitleAddLivemark=Subscribe to Live Bookmark
+dialogTitleAddLivemark=Subscribe with Live Bookmark

in browser/places/bookmarkProperties.properties.

CCing our l10n watcher to get some bugmail noise out, too.

... and earlier changes to that file, too.

Dietrich, patches like that should get an r-.

i posted in mozilla.dev.l10n, really sorry for that Axel, was my fault :(

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

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

Note that Bug 419713 which was marked as a duplicate has some workarounds in "Open Book" extension, and customizable in User style 9029. Keywords should should also show from Organize Bookmarks (bottom), the location bar star, and of course Ctrl+D. Mentioned particularly because in Organize Bookmarks Description etc will take up space from main list, so would want specific control there of what appears there before using the More button.

Edward, I believe this is a dupe of bug 392143?

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

Alex, what is left to do here from a UI perspective?

*** This bug has been marked as a duplicate of bug 405795 ***

This bug is about the keyword, and that bug includes the URL and proposes a different solution.

(In reply to comment #7)
> Edward, I believe this is a dupe of bug 392143?

That's a Firefox bug, this is not.

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

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

Unless Alex has something against this (in such a case feel free to reopen and elaborate on that), i'm going to mark this as WFM based on changes in bug 411261 and followers, further changes should have their own bug.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090619 Shiretoko/3.5pre

Aleksej and reporter, I agree very much with the goal of this bug, but I think it should be resolved duplicate of 405795 as proposed by Shawn in comment #7, for the following reasons:

1) This bug covers a very small subset (make *Keywords* accesible via "Add/Edit this bookmark" / Bookmark Properties dialogues) of bug 405795 (make *all properties* accessible for the dialogues).

2) If your preferred solution is to have the Keywords property visible /at all times/ (without ever clicking more-button to expand the dialogue): this won't happen. Bug 405795 comment #15 leaves no doubt that the minimal ("streamlined" / "crippled") design of the dialogue is intended and only light-weight ("non-obtrusive") additions will be accepted. As much as I am in favour of making the dialogue expandable to edit all properties, I think adding only "Keywords" property permanently to the reduced(!) dialogue would be very confusing: Average user won't know the difference between tags and keywords.

3) With 2) in mind, I think there are only 2 possible solutions for this bug:

a) make reduced "Edit this bookmark" dialogue expandable (more-button) to edit all the properties of a bookmark /inside/ the dialogue. IMO, this is the most-needed and most intuitive option.

b) add a button that links to some other way of editing all properties /outside/ the reduced dialogue (all properties window, "Open containing folder in Library" etc.). IMO, this alone(!) makes it unnecessarily complex to edit the props.

c) combine a) and b): expandable properties dialogue AND "Open containing folder in Library" button (cf. bug 469441). IMO, this is the best solution with added value.

All these possible solutions are covered and discussed in bug 405795. I have proposed a sample UI of the expandable dialogue in bug 405975 attachment 392075, which solves the problem of this bug by combining the best of a) and b).
In other words: we should focus our energy on finding a good solution for bug 405795 that makes everyone happy.

Aleksej and reporter, any objections against resolving this bug as a duplicate?

Can we please remove wontfix? nomination from this bug?
It's an insult in the face of 10 votes, several duplicates, more votes at bug 405795, and especially the outstanding popularity of Firefox's unique "smart keyword" feature, as can be seen from google search results like the following:
http://www.google.com/search?q=Firefox%20bookmark%20keywords

(In reply to comment #10)
> Can we please remove wontfix? nomination from this bug?
No, unless a module owner does so. It's nominated for wontfix by a module peer, and the module owner will take a look at it at some point.

It's good to know that you have your hierarchies all sorted. We also get a sense where the user might be in that hierarchy: somewhere far down at low interest level. To assist with taking an informed look at it "at some point", here's some references both future and past all asking for the same thing: Can we please have some easy way of adding a keyword while bookmarking pages?

http://forums.mozillazine.org/viewtopic.php?f=8&t=1431655
https://bugs.launchpad.net/firefox/+bug/237679
http://forums.mozillazine.org/viewtopic.php?f=38&t=552496&start=0
http://forums.mozillazine.org/viewtopic.php?f=23&t=687835&start=0
http://forums.mozillazine.org/viewtopic.php?t=650888
http://forums.mozillazine.org/viewtopic.php?f=7&t=179600
http://forums.mozillazine.org/viewtopic.php?p=350092
http://forums.mozillazine.org/viewtopic.php?f=38&t=482646&p=2578288

This usage of keywords looks like misuse as tags, keywords adding natural UI is: right click a search field and choose "add a keyword for this search". Otherwise looks like you want a tag on your bookmark.
We need clear use-cases that are not "type g and press enter to go to Google" obviously.

And the awesomebar can find bookmarks quite efficiently typing partial content, thus removing the need for a short "nickname" for the bookmark that we had in FX2.

Users are on top of the hierachy, but even if Firefox is built to accomplish satisfaction in most users, it just can't satisfy every user. That's why we have a user experience team, module owners and so on, to be able to take decisions that we think are good for most users, but maybe they won't be for all of them (with hundreds millions users you can understand how hard that can be). And that's also why extensions do exist, and i'm pretty sure an extension that does that already exists as of today.

that said, i won't spam anymore here, all the needed requests are filed.

(In reply to comment #13)
Thanks for that comment, it was helpful to understand your personal perception of keywords and thus your problem with this bug. Marco, are you using keywords yourself? As a location bar keyboard shortcut for opening URLs with and without query parameters? Looking at comment #13, I guess not...

> This usage of keywords looks like misuse as tags, keywords adding natural UI
> is: right click a search field and choose "add a keyword for this search".
> Otherwise looks like you want a tag on your bookmark...
> And the awesomebar can find bookmarks quite efficiently typing partial
> content, thus removing the need for a short "nickname" for the bookmark that
> we had in FX2.

Absolutely NOT. You _cannot_ use a tag instead of a keyword as a keyboard shortcut to _reliably_ open a static URL with as few steps as possible. The functionality is very different, and in most cases, it simply won't work (since location bar autocomplete is based on frecency more than on keyword matches, and they're competing with your history matches). Even defining a _unique_ tag will _not_ ensure autocomplete match from location bar, so tags are pretty useless as a shortcut for specific urls (I can provide STR for a test case, if needed). Whereas the _keyword_ shortcut works 100% of the time, and guaranteed hassle-free: Ctrl+L, type keyword, press Enter - you're there. Works like a charme, without thinking, parsing, cursoring and everything, straight from your muscle memory. Always.

So keywords provide valuable functionality for highly efficient browsing; therefore, adding keywords to a bookmark should be easy. It's way too hard now (especially when creating a new bookmark; quote below from http://forums.mozillazine.org/viewtopic.php?f=8&t=1431655):

-------------------------------------------------------------
Actual Behaviour (missing on comment #0):

> Right now, to assign a keyword, we have to do this:
>
> . select bookmark this page
> . ctrl+shift+B
> . search for the bookmark
> . select "more"
> . enter the keyword
> . close
>
> #-o [-( The insanity of it all!!! 8-[
-------------------------------------------------------------
Yes, it's insane. Therefore this bug. Access to all properties of a bookmark from it's most prominent representation (the star) should NOT need extensions.

A simple fix that can make virtually everyone happy has been proposed in bug 405795:
-> Add some sort of tiny [v] more button to expand the crippled "Edit this bookmark" dialogue (cf. mockup screenshots, attachment 391888, attachment 392075, attachment 392887)

The fact that we are deliberately hiding valuable functionality (keywords) to an extent that the average user will never find it, is also detrimental to Firefox adoption (cf. comment #0):
> ...but why, oh why are bookmark keywords so shunned! They're an awesome
> feature, but hardly anybody knows about them because you don't even
> see them unless you venture into bookmark manager.

From a Mozilla inside perspective, the article "How Cool are Custom Keywords" by Mozilla's Asa Dotzler looks pretty much supportive of this view (http://www.mozilla.org/docs/end-user/keywords.html). I know Asa from the Mozilla ...

(In reply to comment #13)
> We need clear use-cases that are not "type g and press enter to go to Google"
> obviously.

OK, maybe this usage quoted from "How Cool are Custom Keywords?" (by Mozilla's Asa Dotzler) is good enough? (http://www.mozilla.org/docs/end-user/keywords.html, my emphasis):

> Mozilla Custom Keywords ROCK! Not just for making *shorthand for bookmarks*
> but also for searches and queries. Simple keywords allow you to type a short
> string in the Location Bar and load its corresponding Bookmark URL.
>
> *An example is my bookmark for http://www.mozilla.org to which I've added the
> keyword "m.o".* So, with that set, I can type "m.o" in the Location Bar and
> it loads http://www.mozilla.org. Using keywords combined with autocomplete in
> Mozilla and I seldom type more than about three or four characters for all of
> the sites I regularly visit.

As requested by comment #13, here's some more "clear use-cases that are not 'type g and press enter to go to Google'" (some of my keyword shortcuts for loading _static_ URLs):

mo -> www.mozilla.org (Sites of personal interest; all with similar names and thus usually not directly addressable via location bar matches)
mz -> www.mozillazine.org
mdc -> https://developer.mozilla.org/En (*)
xul -> https://developer.mozilla.org/En/XUL (*)
bzo -> www.bugzilla.org (important portals)
wpo -> www.wikipedia.org (reference works start pages)
sh -> www.selfhtml.org
shf -> http://forum.de.selfhtml.org (forum entry pages of all sorts)
he -> http://htmledit.squarefree.com/ (Real time HTML Editor)
abc -> www.abc-school.de (my workplace; this is not the real link)
ob -> www.my-bank.de/onlinebanking (my bank account; not the real link)
ucc -> www.xe.com/ucc/ (Universal currency converter)
yt -> www.youtube.com (sites where the start page provides appetizers)
zw -> www.sokwanele.com/thisiszimbabwe (news sites of personal interest)

All of these I am using on a daily basis for the fastest possible access to my favourite sites (_static_ URLs). In addition, I have a lot of smart keywords for "query URLs". With millions of users, I'm sure a _lot_ of people will use this in a similar way. HTH.

(*) "mdc" and "xul" as shortcut keyword for Mozilla Devolper Center / XUL Project are two more good examples why tagging just won't do the trick: after typing "mdc" / "xul" in location bar, you'd get countless matching pages from your browsing history on MDC / XUL. On the other hand, hit "Enter" after your favorite shortcut keyword and it'll get you straight to the respective pages. No fuss, 100% of the time.

> keywords adding natural UI is: right click a search field and choose "add a
> keyword for this search".

Unfortunately, we can't set keywords for _static_ urls using this method.
In addition, even for query URLs, the context menu method won't work for certain cases (e.g. http://maps.google.com/) and will create untidy URLs with unknown and unnecessary parameters set. All of these problems would be easily cured by making all bookmark properties accessible from the respective bookmark dialogues (Bug 405795).

We will provide an updated bookmarking UI soon, that *could* satisfy your needs, as it could not. Firefox is designed to satisfy most users, not always any user, unfortunatly. You are free to partecipate to the design discussions with our UX team. We will soon post mockups to get feedback, as we are used to do, it's wrong to think we don't listen, we just have to make choices.

I see your passion, and it's fine, but please be polite toward us.

This bugs as "extend current star panel with additional fields", even if hidden, is still wontfix imo, but new design could probably have space to reduce the user road toward keywords.

(In reply to comment #14)
> (In reply to comment #13)
> You _cannot_ use a tag instead of a keyword as a keyboard
> shortcut to _reliably_ open a static URL with as few steps as possible. ...
> In most cases, it simply won't work (since location bar autocomplete is based
> on frecency more than on keyword matches,

typo fix: Using tag instead of keyword often won't work because location bar autocomplete finds and orders matches based on frecency more than based on _*tag*_ matches, and so tag matches are competing with your history matches, which are likely to be listed near the top.

So while a bookmark with matching tag might not even show on the autocomplete list at all, a bookmark with a matching keyword will always show at the very top of autocomplete list (but I won't even need the list as I just use the keyword).

(In reply to comment #16)
> We will provide an updated bookmarking UI soon,

Let's hope that this is good news.

> Firefox is designed to satisfy most users, not always any user, unfortunatly.
> ...we just have to make choices.

I fully understand and accept this. My point is that in this particular case, there are two proposed solutions in bug 405795 that could satisfy everyone without losing anything (don't change the reduced dialogue so as to keep it simple, but add a tiny toggle to make it expandable as we do in bookmark manager properties pane).

> We will soon post mockups to get feedback, as we are used to
> do, it's wrong to think we don't listen

Thank you for listening, and I'm sure you do. I think it's when easy solutions with a lot of benefit but no or virtually no negative impact get rejected without good arguments (or even wrong arguments), that we might feel not listened to. I know it's tricky because "good arguments" are hard to define, and tend to vary from different points of view.

Where will the mockups be posted? Can you leave a note on this bug when they are?

> This bugs as "extend current star panel with additional fields", even if
> hidden, is still wontfix imo, but new design could probably have space to
> reduce the user road toward keywords.

I accept that we want to keep the reduced star panel as a default, but unfortunately I'm perfectly failing to see what's wrong with making it expandable (which really seems the shortest and most intuitive road)...
As a way out, maybe we can try along Alex' proposal of bug 405795, comment #20 (completely unobtrusive "expand to window" icon, tear-off-approach), explained in bug 405795, comment #25 and welcomed by Marco in bug 405795, comment #24. :)

Marco, you think we could duplicate this against bug 405795 (as proposed by Shawn in comment #7, and explained in comment #9 with no reply or objection from reporter or Aleksej, who wanted to keep this separate in comment #8)?
Inaccessibility of keywords from "Edit this bookmark" dialogue seems to be a subset of bug 405795 in that Description, URL (cf. bug 518423), and bookmark's folder are also inaccessible, and if anything, we'd probably want a unified approach that makes _all_ properties available somehow...

Finally (@FF devs and contributors), thanks for all the good work you do, we've seen some great improvem...

(In reply to comment #17)
> Where will the mockups be posted? Can you leave a note on this bug when they
> are?

bug 524071 is aimed to add an UI that will provide all fields at a click distance, the current idea is a right sidebar. Please avoid long comments, try to be concide, Alex needs a clean bug, so any suggestion should be expressed in a few words and/or point to a newgroups discussion in moz.dev.apps.firefox.

> I accept that we want to keep the reduced star panel as a default, but
> unfortunately I'm perfectly failing to see what's wrong with making it
> expandable

not all the users are good with expandable UIs, especially basic users tend to forget they can contract panels. moreover that panel was intended to allow really quick bookmarking, and it already has too many controls in it, it should be small and sleak, while already now it appears bloated.

> Marco, you think we could duplicate this against bug 405795 (as proposed by
> Shawn in comment #7, and explained in comment #9 with no reply or objection
> from reporter or Aleksej, who wanted to keep this separate in comment #8)?

Imho that's the right choice, as you want keywords, some other user could want description, and so on, so there is not much difference to bug 405795

Interestingly, Firefox 3.7 / 4.0 are actually heading for a powerful _EXPANSION of keywords magic_ by introducing TASKFOX*, which will see a _massive_ return of a familiar use pattern... :

(from: https://wiki.mozilla.org/Taskfox/Use_Cases)
* Select part of the page you want to send
* Type into address bar: "email this to blair" ["map this" | "weather" | etc.]
* Hit enter

:)))

(In reply to comment #17)
Thanks for pointing out bug 524071, up since 2009-10-23, mentioning that one a bit earlier might have avoided a lot of discussion around here...

*: https://wiki.mozilla.org/Firefox/Projects/3.7_and_4.0_Theme_and_UI_Revamp/Direction_and_Feedback#Merging_the_LocationBar_and_SearchBar

(In reply to comment #19)
> Interestingly, Firefox 3.7 / 4.0 are actually heading for a powerful _EXPANSION
> of keywords magic_ by introducing TASKFOX*, which will see a _massive_ return
> of a familiar use pattern... :

While one of the ideas I explored in Taskfox was to improve support for the existing keyword functionality, I don't think its relevant to this bug.

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

I see that no one is working on this bug. I would be willing to volunteer my time to help fix this, yet I don't know much programming. Does anyone know how I can access the code and what computer language this is written in?

<email address hidden>

Firefox is written in C++ on the backend and XUL (easy if you know HTML) and Javascript on the frontend. Source code info: https://developer.mozilla.org/En/Developer_Guide/Source_Code

We don't plan to add keywords to the default UI, whether we'll provide an alternative "full-edit" UI is bug 405795, there is no other plan to do partial changes.

*** This bug has been marked as a duplicate of bug 405795 ***