Bookmarklets (bookmarks with javascript: URLs) should have a different icon than normal bookmarks, since they rarely just take you to a static URL, and since it would make sense to want to scan the bookmarks menu for either normal bookmarks or bookmarklets.

See also bug 59330, "[rfe] IE favorite folder and ftp folders should have special icons".

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.

Mass move Ben's bugs dumped on me marked future with p5 to get off my untriaged radar. You can filter out this email by looking for "ironstomachaussie"

mass reassign of pchen bookmark bugs to ben

This should probably be generalized to having different default bookmark icons depending on the protocol part of the URL. That way there would be different icons for web (http://), JavaScript (javascript:), IRC (irc://), news posts (news:), etc. bookmarks.

> This should probably be generalized to having different default bookmark icons > depending on the protocol part of the URL. [...] The icons could be made via CSS :before pseudo class. In bug 102912 comment 15 I suggested 2 ways to do this. Since the selector [href^="http://"] is already implemented (1.0rc1) the second would be the best way IMHO. Example: [href^="http://"]:before { content: url("chrome://http.png"); } [href^="mailto:"]:before { content: url("chrome://mailto.png"); font-style: italic;... }

Add the following to your userChrome.css and the bookmarklets will stand out quite nicely: /* Mark the bookmarklets with special icons in the Personal Toolbar */ .bookmark-item[id^="javascript"] > .toolbarbutton-icon { list-style-image: url("chrome://communicator/skin/bookmarks/bookmark-item-updated.gif") !important; } /* Mark bookmarklets with special icons in the bookmarks menu */ menuitem.bookmark-item[id^="javascript"] > .menu-iconic-left { list-style-image: url("chrome://communicator/skin/bookmarks/bookmark-item-updated.gif") !important; } (This works assuming you're using the classic theme and not using bookmark change notifications that update the bookmark icon.) A real fix would include creating a bookmarklet-specific icon. I just picked one that was easily available. The actual fix could be applied to bookmarks.css in skin\classic\communicator\bookmarks. This could be extended to have special icons for ftp, irc, news, or whatever. All you do is change the "javascript" to the appropriate protocol. This works with Mozilla nightly 2002083008 on windows 2000.

I'd recomend making that [id^="javascript:"] (with a colon) because otherwise it would break if someone made, e.g., a javascript-console: scheme or whatever.

The bookmarks rewrite broke the userchrome fix I suggested below because bookmarks no longer use the URL as the id. Using statustext instead of id works for the personal toolbar, but doesn't work in the menus. However, we could add statustext for the menus as well.

After applying the patch, adding the following to userchrome will cause the bookmarklets to have a different icon on the personal toolbar and in the menus: Adding the following to userChrome.css will fix the problem for the Personal Toolbar because the statustext now contains the URL: /* Mark the bookmarklets with special icons in the Personal Toolbar */ /* Fix for bug 72374 */ .bookmark-item[statustext^="javascript:"] { list-style-image: url("chrome://communicator/skin/bookmarks/bookmark-item-updated.gif") !important; } /* Mark bookmarklets with special icons in the bookmarks menu */ .menuitem-iconic.bookmark-item[statustext^="javascript:"] { list-style-image: url("chrome://communicator/skin/bookmarks/bookmark-item-updated.gif") !important; }

I've written a page that describes how to fix this for the classic and modern themes and includes patches for the themes and suggested icons for the bookmarklets. http://www.worldtimzone.com/mozilla/bugs/bug72374/ I've noticed that this doesn't fix the bookmarklets icon in the bookmark manager or in the bookmarks sidebar. It appears I need to do something like: treechildren::-moz-tree-image(Name, javascripturl) { list-style-image: url("chrome://communicator/skin/bookmarks/bookmarklet.gif"); } but I'm not sure where to add the javascripturl property to the bookmarks tree. Is there any way to have the image in one column depend on the data in a different column in the tree? Suggestions?

Comment on attachment 128019 [details] [diff] [review] patch to add statustext to the bookmark menus nice patch here. Neil, can you review this?

Shouldn't that patch be on bug 23460?

Comment on attachment 128019 [details] [diff] [review] patch to add statustext to the bookmark menus Seamonkey doesn't have the XUL/XBL statustext changes necessary for this patch; feel free to submit a combined patch.

Is there a Firefox version of this bug?

http://forums.mozillazine.org/viewtopic.php?t=81491 has another workaround.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Confirming... Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090614 SeaMonkey/2.0b1pre

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Reconfirming again.

Would like to see this implemented in Firefox 5. This bug has been open for around 10 years with no considerable activity on it. :(

I agree completely with getting this functional, I use bookmarklets daily and honestly could not function as efficiently or pleasurably with out them. making them more visible with custom icons with out having to tack in a huge Uri encoded image would be wonderful.

Bug 482166 seems to be looking for a more general approach, not only for bookmarklets but also for FTP sites and such. Not quite a duplication, but maybe a dependence?

Bug 109669 is the metabug and already in the dependency list.

Looks still valid