Closed Bug 10197 Opened 25 years ago Closed 13 years ago

Show whether the current page is in the user's bookmarks.

Categories

(SeaMonkey :: Bookmarks & History, enhancement, P3)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: CodeMachine, Unassigned)

References

Details

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.
Summary: Show whether the current page is in the user's bookmarks.
Component: Browser-General → XPApps
Summary: Show whether the current page is in the user's bookmarks. → [RFE] Show whether the current page is in the user's bookmarks.
Target Milestone: M14
QA Contact: leger → don
Target Milestone: M14 → M20
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.
Target Milestone: M20 → Future
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.
Assignee: don → mozilla
Status: NEW → ASSIGNED
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
Assignee: mozilla → don
Status: ASSIGNED → NEW
QA Contact: don → sairuh
over to bookmarks...
Assignee: don → slamm
Component: XP Apps → Bookmarks
QA Contact: sairuh → claudius
Depends on: 55175
Depends on: 41502
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
Assignee: slamm → ben
nav triage team:

marking nsbeta1-
Keywords: 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.
Status: NEW → ASSIGNED
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'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → 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).
Summary: [RFE] Show whether the current page is in the user's bookmarks. → Show whether the current page is in the user's bookmarks.
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.
Product: Browser → Seamonkey
Assignee: bugs → nobody
QA Contact: claudius → bookmarks
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
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
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
At some point, this was implemented.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME

    
    

    
  
(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.

          You need to log in
          before you can comment on or make changes to this bug.