Quoting a newsgroup posting: --- Subject: Bookmark management wish Date: Thu, 15 Jul 1999 15:00:23 +0100 From: Alien Conspiracy <alien.conspiracy@dial.pipex.com> Organization: Another Netscape Collabra Server User Newsgroups: netscape.public.mozilla.wishlist Hi All, I don't know if this is a common problem or just me, but I often indevertently bookmark pages that are already in my bookmark list. So it would be nice if: (1) There was some on-screen indication as to wether the page currently being viewed is bookmarked or not. (2) The 'add bookmark' command checked the existing bookmarks and warned me if it's a duplicate. Cheers! --- This bug report concerns only the first, showing the status.

Updating milestone

Implementation: * Disable any `Add bookmark' menu items/buttons. (Don't provide any other feedback: the bookmarked-or-not status of the current location isn't important enough to be on the screen all the time.) * If the user opens the bookmarks window from a browser window containing an URL which is bookmarked, open the bookmarks window with that URL showing. This could be annoying if I, for some reason, want to add more than one bookmark for the same location. I can't think of a reason why I'd want to, but you can be pretty sure *someone* will have a reason. So, perhaps a `check for duplicates' function in the bookmarks window itself would be more useful, instead. Of course, the whole problem of telling whether a given page is in the bookmarks or not is fraught with difficulty. E.g. on many sites, these are all the same page, but have different addresses: * http://foo.bar * http://www.foo.bar * http://foo.bar/ * http://www.foo.bar/ * http://foo.bar/index.html * http://www.foo.bar/index.html

Mozilla converts http://foo.bar to http://foo.bar/ automatically, but mpt's point still holds.

Move to "Future" milestone.

this sounds like a good candidate for "helpwanted"...

... Or a good candidate for RESOLVED IMPOSSIBLE. :-)

Reassigning to myself. No promises, but I have an idea on how to proceed. If anyone who actually knows what they're doing wants to take over, go for it.

ditching, i regret that i do not have the time to work on this what needs to be done: when adding a new bookmark, search for the current location in exsisting bookmarks (not concerned with permutations mpt described) also, the page title could also be checked for dupes. the dialog that pops up could offer options such as: 1) ignore, add possible duplicate 2) remove duplicate, add new bookmark the use of this is, if we have a match on location, the new title of the page can replace the old. of if we have a match on title, the new location can replace the old. 3) cancel (ie, thanks, i forgot this was bookmarked already... i dont need 2!) the dialog should show all the information we keep on the other bookmark... title, addess, last visited... maybe a 'view page' button to open a fresh window to check out the possible duplicate. bugs waiting to happen: what to do when there are multiple matches, or 1 match for location, 1 for title... i see this going nobody@/FUTURE/helpwanted, but assigning to default owner

over to bookmarks...

Reassigning 79 Bookmarks bugs to Ben. I was told this was going to be done shortly about two months ago, but it clearly hasn't been. I think that's long enough for all these bugs to remain assigned to nobody. Feel free to filter all this spam into the trashcan by looking for this string in the message body: ducksgoquack

nav triage team: marking nsbeta1-

adding cc

Netscape Nav Triage Team: adding german to the cc list - UE please comment.

I'm not convinced this is worth any significant development effort; let alone runtime overhead as it churns through an unbounded bookmark file. If there really is a problem with duplicate bookmarks, I think it could be handled adequately by a separate dup search.

If perf was an issue this could certainly be restricted to a warning when you add a bookmark.

Would it make sense UI-wise to use a different proxy icon for bookmarked pages? Btw, making a warning appear when adding a second bookmark to the same site is bug 10198.

ayup. I'm thinking there needs to be some sort of easy way to set the icon next to the urlbar when the page loads, to either show that the page is bookmarked (with a special icon) or a custom icon for the page (similar to favicon.ico) Peter - there'd be no "churn" really... the bookmarks datasource is already loaded, these would be the steps: Page load, then: - get resource for URL (RDFService.GetResource("http://www.goat.com/")) - check to see if resource has rdf:type arc out to NC:Bookmark resource. If so, page bookmarked - twiddle icon next to urlbar Else - nothing This would add a /little/ time to page load, although not much.

Well, the default icon that's on the URL bar is a bookmark already, so that's pretty dumb, and doesn't help us here. Ok, so, how about this for the image... A simple default graphic that somehow indicates "site" or "page". If the page has a <link rel=favicon> deal, that's used (seperate bug) If it's bookmarked, we superimpose the blue-green ribbon thing on the default or favicon already there.

I think we should be worrying about how to make page load and bookmarks faster, not how to add marginal featurs, let alone make them slower.

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

mass reassign of pchen bookmark bugs to ben

I think bug 117162 is a duplicate of this one.

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

As a serious bookmark user, I agree this would be a great feature to have. I like Jeremy's UI suggestion for the feature (mentioned in comment #18 above). Since it would slow down page load times, then I suggest that it's a perference that could easily be turned on or off (probably should default to off).

A UI that would probably be more obvious to users it to change the 'Add Bookmark' menuitem to 'Bookmarked' and then put a check next to it if the current page is bookmarked, no check otherwise. We'd have to consider the effect of selecting the checked "Bookmarked" menuitem, but I'd suggest it should un-bookmark the page. This could be done in addition to the icon, which would be way neat ;-) BTW: The performance impact of a well-chosen search algorithm on even a 1000 item bookmark file should be negligable. Think about it, we do the same thing --- except on a larger file --- for determining if links are visited. Or if a file is in cache. Etc.

A way to UNbookmark the current page as Anthony described would definately be neat. I often bookmark pages at the end of the day, intending to get to them the next day. Soon as I load each one, I have do bookmarks, manage bookmarks, scroll all the way to the bottom, click delete, and close the window. One question. Do we want there to be any way for a user to have two bookmarks to the same URL? Is it a lot of arch changes? If so, I vote we disallow it on that alone, and go ahead with UI similar to this. I suspect IE has issues with two bookmarks with the same name (URL would be irrelevant for IE's storage method) in the same bookmark folder, as well.

Personally, I think this should only be considered as part of the Add Bookmark function so that it doesn't use any cpu cycles while selecting a bookmark and loading the page. That said, I also think the dependencies should be updated. Remove the Depends-On references to 41502 and 55175, and instead add bug 141227.

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

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

At some point, this was implemented.

(In reply to comment #35) > At some point, this was implemented. What is the UI for this? I don't see it on SM 2.0.11.

The "Star bookmark" quick bookmark panel in 2.1b2pre will tell you how many times you've bookmarked the current page.

(In reply to comment #37) > The "Star bookmark" quick bookmark panel in 2.1b2pre will tell you how many > times you've bookmarked the current page. Ah, thanks for the clarification.