72374 - different icons for bookmarklets and normal bookmarks

Status: NEW

(SeaMonkey :: Bookmarks & History, enhancement)

Description

[Jesse Ruderman]

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.

Comment 1

[Jesse Ruderman]

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

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 3

[Paul Chen]

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"

Comment 4

[Peter Trudelle]

mass reassign of pchen bookmark bugs to ben

Comment 5

[Garth Wallace]

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.

Comment 6

[Sascha Claus]

> 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;...
}

Comment 7

[Tim Powell]

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.

Comment 8

[Hixie (not reading bugmail)]

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.

Comment 9

[Tim Powell]

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.

Comment 10

[Tim Powell]

Attachment: patch to add statustext to the bookmark menus

Comment 11

[Tim Powell]

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;
}

Comment 12

[Tim Powell]

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 13

[Daniel Wang]

Comment on attachment 128019 [details] [diff] [review]
patch to add statustext to the bookmark menus

nice patch here. Neil, can you review this?

Comment 14

[Jesse Ruderman]

Shouldn't that patch be on bug 23460?

Comment 15

[[e-mail]]

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.

Comment 16

[Phillip Stewart :P]

Is there a Firefox version of this bug?

Comment 17

[Jesse Ruderman]

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

Comment 18

[Robert Kaiser]

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

Comment 19

[Robert Kaiser]

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

Comment 20

[Robert Kaiser]

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

Comment 21

[Robert Kaiser]

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

Comment 22

[Robert Kaiser]

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

Comment 23

[Biju]

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

Comment 24

[Robert Kaiser]

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

Comment 25

[Garth Wallace]

Reconfirming again.

Comment 26

[Siddhartha Dugar [:sdrocking]]

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

Comment 27

[Taylor Suchan]

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.

Comment 28

[Marcelo Bastos]

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?

Comment 29

[Philip Chee]

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

Comment 30

[Phoenix]

Looks still valid