different icons for bookmarklets and normal bookmarks

NEW
Unassigned

Status

SeaMonkey
Bookmarks & History
--
enhancement
17 years ago
3 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {csectype-spoof, helpwanted, sec-want})

Trunk
Future
csectype-spoof, helpwanted, sec-want
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want P4][2012 Fall Equinox], URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
See also bug 59330, "[rfe] IE favorite folder and ftp folders should have 
special icons".
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → Future
Assignee: ben → pchen
Status: ASSIGNED → NEW
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Comment 3

16 years ago
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"
Priority: -- → P5
(Reporter)

Updated

16 years ago
Blocks: 109669

Comment 4

16 years ago
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben

Comment 5

15 years ago
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

15 years ago
> 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

15 years ago
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.

Updated

15 years ago
Summary: [rfe] different icons for bookmarklets and normal bookmarks → different icons for bookmarklets and normal bookmarks

Comment 9

14 years ago
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

14 years ago
Created attachment 128019 [details] [diff] [review]
patch to add statustext to the bookmark menus

Comment 11

14 years ago
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

14 years ago
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

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

nice patch here. Neil, can you review this?
Attachment #128019 - Flags: review?(neil.parkwaycc.co.uk)
(Reporter)

Comment 14

14 years ago
Shouldn't that patch be on bug 23460?

Comment 15

14 years ago
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.
Attachment #128019 - Flags: review?(neil.parkwaycc.co.uk)

Comment 16

13 years ago
Is there a Firefox version of this bug?
(Reporter)

Comment 17

13 years ago
http://forums.mozillazine.org/viewtopic.php?t=81491 has another workaround.
Product: Browser → Seamonkey
(Reporter)

Updated

11 years ago
Whiteboard: [sg:want P4]
Assignee: bugs → nobody
QA Contact: claudius → bookmarks

Comment 18

8 years ago
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
Status: NEW → UNCONFIRMED

Comment 19

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
Confirming...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre)
Gecko/20090614 SeaMonkey/2.0b1pre
Status: UNCONFIRMED → NEW

Comment 24

8 years ago
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
Status: NEW → UNCONFIRMED

Comment 25

8 years ago
Reconfirming again.
Status: UNCONFIRMED → NEW
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

6 years ago
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

6 years ago
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

6 years ago
Bug 109669 is the metabug and already in the dependency list.
Depends on: 482166
Keywords: sec-want

Comment 30

5 years ago
Looks still valid
OS: Windows 98 → All
Priority: P5 → --
Hardware: x86 → All
Whiteboard: [sg:want P4] → [sg:want P4][2012 Fall Equinox]
(Reporter)

Updated

4 years ago
Keywords: csec-spoof
(Reporter)

Updated

3 years ago
Blocks: 971598
You need to log in before you can comment on or make changes to this bug.