51683 - Unable to have 2 differently named bookmarks for the same url.

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P2)

Description

[David Krause]

BenB created a new bookmarks file that I reviewed.  The file had a link to
http://www.mozilla.org/ in the PT called "mozilla.org" and also a link to
http://www.mozilla.org/ in the main section of bookmarks called "The Mozilla
Organization."  When I tried to use this file by placing it in
mozilla/package/defaults/profile/ and removing my .mozilla directory, I noticed
that the newly created bookmarks both had "The Mozilla Organization."

Then I tried making two links with the same url but different names.  Aftering
entering the second link one of the two entered links disappears.  More info
tomorrow, going to sleep now.

Comment 1

[Ben Bucksch (:BenB)]

I must be able to have 2 bookmarks (possibly under different folders) with the
same url, but different names. Heck, 4.x even had a special feature, aliases,
for that. And certainly, bookmarks shouldn't disappear. nsbeta3.

Comment 2

[R.K.Aa.]

related to bug 49534 "adding same bookmark >1 times requires equal number of
"delete" ops to remove" (assigned to rjc)

Comment 3

[Claudius Gayle]

lemme get this straight, you can have two bookmarks to the same URL w/ different
names but if you change the name of one the other magically disappears?

Comment 4

[David Krause]

Attachment: bookmarks.html testcase

Comment 5

[David Krause]

There are multiple ways to reproduce:

1. Quit mozilla if it is running.
2. Substitute the attached bookmarks for either the default bookmarks or the
bookmarks in your profile.
3. Observe that one of the descriptions has changed from the way it was in the file.

1. Create a new bookmark to http://www.mozilla.org/ and call it 'mozilla.org'
2. Create a new bookmark to http://www.mozilla.org/ and call it 'moz.org'
3. Observe that only one of the bookmarks now exists.

1. Bookmarks->Add Current Page
2. Bookmarks->Add Current Page
3. Repeat step 1 as many times as you like.
4. Observe that only 1 bookmarks appears no matter how many times you do step 1.

Reproducibility: everytime

Build Date & Platform Bug Found: Linux 2000090508

Comment 6

[johng]

nav triage team:
nsbeta3-, this is an edge case

Comment 7

[timeless]

Clobbering nsbeta3-. This is not an edge case. Normal users will do this.

If I set up a bunch of links for my sister or my mother, but I put them in a 
nice hierarchical tree (because I do things like that), and they can't find it 
(or decide it isn't there) they WILL try to "add bookmark", if this bookmarking 
fails to put it in a top level just because I burried it elsewhere, then we 
have a problem. And I have a few upset family members.

Similarly for QA if one of the steps is to add a bookmark for say 
www.mozilla.org and that's already bookmarked we're saying that it's ok for 
this to fail?

This is unacceptable
</rant>

Don't worry I can crash by adding www.mozilla.org
TB17116269W

Do not nsbeta3- this bug. Thank you ;-)
Steps to reproduce are approximately:
Add bookmark
[in manage bookmarks] Move bookmark to personal toolbar
Add bookmark
If that succeeds, quit, run moz, add again.

Comment 8

[Claudius Gayle]

you said that having two *differently* named bookmarks to the same URL triggered this.
What you are now saying doesn't mesh with your prior statements. According to what you
said earlier your latest repro steps would indeed succeed, over and over again.

The edge case that the nav traige team referred to is that of having two exact same
bookmarks but trying to change the name of one.

Comment 9

[Ben Bucksch (:BenB)]

claudius, see Comments From David Krause 2000-09-07 19:07, 3. variation.

Comment 10

[Claudius Gayle]

two things:
First, the third variation of Krause's repro step's you cite are a different bug totally.
That implies that you can't add two of the EXACT same bookmarks, name, url everything.

Secondly, that's not a bug AT ALL, as a matter of fact I think I remember a previous bug
being fixed that resulted in this behavior. It comes from the idea that you can't have duplicate
bookmarks on the same level of the bookmarks tree. Try those steps again but put the 1st
bookmark in a folder. You can add another copy just fine.

So at best you have what might be a tiny bit of perceived data loss IFF you try to create
duplicate bookmarks w/ different names or they already exist and you try to import them.
Sounds pretty edge to me.
I must also reiterate, the hypothetical you propose is completely untrue. Try it. I did.

Comment 11

[Claudius Gayle]

I just wrote related bug 51942 "dragging a duplicate bookmark *onto* a folder that contains its
copy crashes."

Comment 12

[Ben Bucksch (:BenB)]

Scenario: (compare inital description)
A user adds a page to his bookmarks, and accepts the default title (because it
is much work to change it), and the title of the page happens to be long (very
common). Later, he decides to add this page to his Personal Toolbar. Because the
space there is limited, he wants to shorten the name. He does so, but it has no
effect.
This is not an edge case, but a common scenario for all PT users.

Comment 13

[Jim Roskind]

Dogfood plus to stop the crash only. It would not be obious to a user that the 
crash was induced by a dup, rather than simply by dragging a URL to the 
bookmarks file.
Reading Claudius's tests, I tend to agree that beyond the crash, this is an edge 
case (assuming that his tests are valid, and the hypothetical problems are not 
present).

Timeless: Note that setting the bug to beta3-plus or minus is the job of the 
manager in cooperation with marketing, and has a lot to do with available 
Netscape staffing and time, as well as other bugs that are seemingly even more 
important. Giving it a minus has nothing to do with desire to fix.  Please let 
them do their job on these bugs.  If you have the inclination to help to fix the 
bug, please don't be slowed by the NSbeta3-minus rating, which is only meant to  
help guide Netscape staff in their prioritization. If you feel there is info 
that was not understood when making the minus call, then it is fine to remove 
the minus, and add the explanation. In fact, it is appreciated!  Once the 
argument is on the table, the priority call has to be made by the manager.  
Thanks in advance.

Comment 14

[Blake Ross]

see also bug 46686, which may be related somehow

Comment 15

[Ben Bucksch (:BenB)]

<rant type="bad">
yup, no way to stop Netscape from shipping a crappy product.
And you know what? I don't care anymore. Just deliver full standards
conformance.
</rant>

Comment 16

[Ben Bucksch (:BenB)]

Removing "[NON EDGE CASE]" from status whiteboard, because it is subjective and
should be clear from the summary.

Comment 17

[Blake Ross]

<rant class="we have a product to ship">
there 400 nsbeta3+ bugs alone to fix within about a week, and thousands more 
that, though very important to someone or other, have been futured into 
oblivion.  I feel your pain, because I've watched many important bugs go down 
the drain (not meant to rhyme, i swear!), but if everything that someone really 
felt strongly about was plussed, netscape's shipping date would coincide with 
next millennium's new years party.
</rant>

Keep your fingers crossed that the easiest fix for the crash is the fix for the 
originally reported bug as well.

Comment 18

[David Krause]

Hmm, just discovered another implication of this bug that justifies the dataloss
keyword.  Note that maybe some of these things I am posting might be different
bugs.  They seem so similar to me and related but feel free to open a new bug if
you believe that this is a separate bug.

1) Use the latest bookmarks file that got checked into the tree today.  The
older one might work but I don't know what links where in it exactly.

2) Go to http://www.bugzilla.mozilla.org/ for example.

3) Bookmarks -> Add current page

4) Notice that everything is as expected and the bookmarks was added.

5) Bookmarks -> Modify Bookmarks...

6) Drag the new bugzilla bookmark into the PT for easy access.

7) Write out the bookmarks file and notice that the link to bugzilla in the
Bookmarks->Mozilla Webtools folder is now gone :(

Comment 19

[David Krause]

Err...  Scratch the www from the url in the last comment.

Comment 20

[Claudius Gayle]

crash, what crash? There are no steps listed in this bug save those that I cite as bug 51942.
I question the dogfood+ designation. I've refrained from removing it in case someone points
out sometihng I've missed.

This is an XP issue changing Platform/OS to All/All.

Comment 21

[timeless]

Additional Comments From [e-mail] 2000-09-08 15:47
> Don't worry I can crash by adding www.mozilla.org
> TB17116269W
Claudius: Please pull the incident and attach here. Thanks 

Comment 22

[verah (gone)]

Nav triage team: timeless, can you please give us the steps to reproduce your 
crash?

Comment 23

[don]

Marking this "nsbeta3-" and removing dogfood status.  Nobody else can reproduce
the crash on ANY platform.  And ... we're not changing the other behavior before
ship.

Comment 24

[Jim Roskind]

If this can't be reproduced... please mark it as Works For Me.
If the bug was as indicated, it would probably get the dogfood-plus again, 
especially when noting the crash (timeless commented on the crash, and added the 
keyword on 9/8 above).
If the crash is no longer reproducible, then please remove the crash keyword 
(and then mark this as dogfood-minus).

Comment 25

[Ben Bucksch (:BenB)]

Crash is propably a dup of bug 46686.

Comment 26

[Jim Roskind]

It sounds like the crash element of this bug is being handled by the bug that
Ben just referenced.
The rest of this bug is not dogfood (it is to hard to reproduce).
Marking dogfood-minus.

Comment 27

[David Krause]

Removing crash keyword.  Timeless says he can't reproduce the crash so it was
probably fixed by bug 46686.

The rest of this bug is still occuring.  The easiest way to observe this is to
download the latest build and create a new profile.  Observe that the Personal
Toolbar says "Home | The Mozilla Or... | Latest Builds."  If you look in the
actual http://lxr.mozilla.org/seamonkey/source/profile/defaults/bookmarks.html
file you will see that it is supposed to be "Home | mozilla.org | Latest Builds."

The second occurence of a link to "http://www.mozilla.org" with description "The
Mozilla Organization" in the bookmarks file is causing the first occurence with
description "mozilla.org" to be renamed to "The Mozilla Organization."  This
causes the PT to look ugly since the description in the PT is really long
because of this bug.

Comment 28

[Blake Ross]

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

Comment 29

[R.K.Aa.]

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

Comment 30

[Marcia Knous [:marcia]]

Netscape Nav triage team: this is a Netscape beta stopper.

Comment 31

[Viswanath Ramachandran]

Ben doubts that this is possible for the next release, since this may require
large modifications to the bookmarks service. 

Comment 32

[Claudius Gayle]

We'll never have true and good BM management if there is a fundamental flaw in the way the
bookmarks service handles multiple instances of the same or similar entries. This is such a core
problem that it is the cause of several related but not duplicate bugs. You can sense this if you
read this whole report and see the numerous scenario's where errors pop up.

I would ask that we think very carefully before we decide to let this slide for yet another release.

Note that I completely understand fixing this may mean not getting other much needed fixes.
I submit that leaving this broken adds up to more of everyone's work in the long run. </.02>

Comment 33

[Claudius Gayle]

at first glance bug 41502 seems to be related, noting so that i don't have to look for it later

Comment 34

[Chris McAfee]

.9

Comment 35

[Paul Chen]

nav triage team:

Futured to make room on Ben's plate for 41888

Comment 36

[Paul Chen]

nav triage team:

Forgot to bump down priority to p4

Comment 37

[timeless]

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

Comment 38

[Paul Chen]

nav triage team:

Not going to happen for beta, marking nsbeta1-

Comment 39

[Claudius Gayle]

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

Comment 40

[Chase Tingley]

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

Comment 41

[R.K.Aa.]

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

Comment 42

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 43

[Chris Lyon]

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

Comment 44

[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 45

[Boris Zbarsky [:bzbarsky]]

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

Comment 46

[Chris Lyon]

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

Comment 47

[Claudius Gayle]

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

Comment 48

[Clement Cherlin]

This bug has a further dataloss component: Editing the URL of a duplicate also
edits all bookmarks with that URL.

I was bitten by this when I tried to create a slightly modified version of a "Go
to Selected URL" bookmarklet (Bookmark of a javascript: URL with some useful
function), that would instead "Go to Selected Bugzilla Bug #".

I tried to create a second copy of the bookmark in my Bookmarklets folder, and
couldn't (Bug 41502). Fine. So I created a copy in a different folder. I edited
the Javascript to my satisfaction, and changed the name. I then went to move my
new bookmark back into my Bookmarklets folder, and found that in editing the
copy, I had edited the original! Furthermore, when I deleted the copy, the
original seemed to vanish (Bug 28417).

So now my "Go to Selected URL" bookmarklet is gone. I can get another copy, but
it is very poor that any of this happened in the first place. I agree with
[e-mail]'s assessment of the problem in comment #32, that this "is
a fundamental flaw".

Comment 49

[Peter Trudelle]

mass reassign of pchen bookmark bugs to ben

Comment 50

[Chris Lyon]

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

Comment 51

[Ben Bucksch (:BenB)]

I think that this one should really be fixed for 1.0. A bug like that doesn't
belong in a finished product.

I recently also hit the problem described in comment 48.

Comment 52

[Chris Lyon]

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

Comment 53

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

Not for this release. Requires fundamental changes to bookmarks implementation. 

Comment 54

[Peter Trudelle]

What about preventing this scenario from happening?  Can that be done efficiently?

Comment 55

[xyzzy]

One proposal that somewhat addresses Peter's question is bug 10198.  Although
this would not prohibit duplicates, it would likely get rid of accidental
duplicates.

Comment 56

[Michael Moulton]

I'm not sure why the developers seem to think this isn't a serious bug.  It
basically makes the personal toolbar unusable if you have the same bookmarks
with their full names in other folders.  I'm still running Netscape 4.x because
of it, and other friends have told me they won't switch either until it's fixed.

This is _not_ an edge case and it is one of the most glaring usability bugs in
Mozilla.

Comment 57

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

I prepared a response to Peter's question earlier but my network died and I
forgot to post it. Fixing this bug involves major changes to the bookmarks system.

Background:
- each bookmark is represented by a RDF resource with a URI (.Value) field with
an identifier representing that bookmark.
- currently that identifier is the URL of the bookmark (e.g. http://www.foo.com/)
- using the URL of the bookmark as the URI allows database aggregation to work,
such as live search queries and dynamic views of file system folders. 

Proposed changes (off the top of my head):
- give each bookmark a unique (random) identifier akin to bookmark folders
- hack the template builder to use the 'ref' attribute to determine whether or
not an item has children, and use NC:URL as the property to query for children
in the composite DB.

Michael, developers consider this important, however it has thus far not been
important enough to marketing/management to warrant fixing, as the above tasks
may take some time to perfect. 

Comment 58

[Peter Trudelle]

nsbeta1- per Nav triage team. too late in MachV to be considering architectural
changes.

Comment 59

[Michael Moulton]

Maybe I just don't have a complete understanding of the Mozilla bug-fixing
process, but I am really stunned that a bug could exist for a year and a half
and then suddenly it's "too late to be considering architectural changes."

Comment 60

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

Michael, developers consider this important, however it has thus far not been
important enough to marketing/management to warrant fixing, as the above tasks
may take some time to perfect. 

There seems to be some interest in this bug now though, so plans to fix it will
probably be made after 1.0. 

Comment 61

[Michael Moulton]

Ben,
I see your point and understand what you're saying.  However, 1.0 is supposed to
be a "stable" release, and I just don't see how a major flaw in the design of
the bookmarks system that has been documented for 18 months can be allowed to
remain in a supposedly "stable" release.

Comment 62

[Adam Hauner]

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

Comment 63

[Chris Lyon]

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

Comment 64

[Peter Trudelle]

If someone can get a clean fix for this through the gauntlet, I'll sure applaud,
but at this point we have to be very careful about introducing worse regressions.

Comment 65

[Boris Zbarsky [:bzbarsky]]

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

Comment 66

[Tony Tovar]

How did Netscape 4.x get around this?  Did it *not* need identifiers, e.g. the
RDFs mentioned in comment 57 ?

As it is, it seems like we've simply traded functionalities, i.e., ability to
file dupe bookmarks vs. ability to do "database aggregation" (again, from
comment 57), while also creating some new bugs.  The current summary sounds like
an RFE to me, while some of the other testcases sounds like normal bugs (but not
severity=major).

Can this bug be made into a meta bug, e.g. "New bookmark.html system breaks some
functionality" and have these other testcases made into new blocking bugs?  Bug
41502 could then be changed from a blocked to a blocker.

P.S. I've never had a problem with the current system, so I apologize if I seem
to be "making light" of this bug.

Comment 67

[Michael Moulton]

Netscape 4.x doesn't seem to use any identifiers for the bookmarks.  Each
bookmark is simply a table entry in a standard HTML file.

I find this to be a major bug b/c the insistence on single descriptions for each
bookmark makes the Personal Toolbar basically unusable unless you are willing to
shorten the descriptions of the bookmarks in every instance-- which is a major
hassle.  There are people who refuse to run Mozilla/Netscape 6/anything else
using this bookmark system b/c of this bug.  I'm one of them, many of my friends
are the same way.

Comment 68

[Tony Tovar]

I agree with everyone who is complaining that this wasn't addressed a long time
ago.  I can understand, though, how it kept being delayed -- an architectural
change to the bookmarking system is going to set off a flurry of bugs!  The
developers' optimism about the 1.0 release-date surely made them think they
didn't have time to get into it.  Now that 1.0 has really arrived, the important
thing is to minimize the impact of this design flaw, e.g. fix bug 10198.  It
should also be clearly explained in the Release Notes.

Then, I propose that this bug be changed into a meta/tracking bug for the 1.1
architectural change.

Comment 69

[Andrew Hagen]

Proposed relnote for Mozilla 1.0: Having two bookmarks of the same URI with
different names is not supported in this release.

BTW, please don't morph this bug into something else. You could open a separate
tracking bug for the changes that we need for 1.1, though.

Comment 70

[Michael Moulton]

I agree that this bug should not be changed into something else.
10198 being fixed would definitely be good.  But the capability still NEEDS to
exist to have duplicate bookmarks with different names.

Comment 71

[Tony Tovar]

Created bug 141227 "(meta) proposed changes to bookmarks system" to track needed
changes.  Now I just need someone to mark it as NEW.

Then, I suggest that we shift this bug (and it's blocked bug-list) to the
tracking bug.  I'm not going to do myself, though, because I don't want to step
on any toes.  Is this acceptable?

Comment 72

[Boris Zbarsky [:bzbarsky]]

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

Comment 73

[Gray]

I've run into this problem with links to the same host but _different_ ports.
You cannot have a link to foo.com[:80] and foo.com:83 without them being
considered the same.

Sorry for the naice suggestion but can the unique ID be attached to the host/port
combination?  This would be an improvement.  Thanks.

Comment 74

[Tony Tovar]

Should the summary for this bug be changed, e.g. "[RFE] allow duplicate URL/port
in bookmarks"?

(Adding as blocker to tracker for proposed bookmark changes, bug 141227)

Comment 75

[The Cunctator]

I wouldn't think so. This is a bug, not an RFE.

Comment 76

[Adam Hauner]

Tony Tovar: fill new bug report with port issue.

Comment 77

[Gray]

I already submitted 141323.  I've resubmitted it not as a duplicate and I've
changes the summary to indicate the port issue.

Comment 78

[mental]

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

Comment 79

[Dave]

I think there are effects that clearly belong to this bug, but are not
represented in its summary.  I can produce (on Win 98 Build 2002050608) the
following effects that seem to fall under this bug's heading:
~~~~~~~~~~~
1)  Changing bookmark A's URL to URL U causes all other bookmarks B with URL U
to take on all properties of bookmark A (Name, Keyword, Description, etc.).
2)  Once a set of bookmarks (A, B,...) have been "synchronized" (as described
above) changing any property (including the URL) in any bookmark in the set,
changes that property in all other bookmarks in the set.
3)  If bookmark A for URL U already exists, or existed at any time since the
last time all instances of Mozilla were closed (but was since deleted), creating
bookmark B for URL U causes bookmark B to inherit the properties of bookmark A.
 (To clarify, this happens even if bookmark A was deleted, but not if all
Mozilla instances were closed after bookmark A was deleted).
This last observation is not meant to include the unrelated issue of deleted
bookmark data still being around.  The only reason I have included that is to
have a complete description; hopefully it will not be important if this bug is
fixed.
And when I say change a bookmark property, I mean through the Mozilla GUI.
~~~~~~~~~~~
In Comment 57, Ben tells us that the bookmark URL is used as the key for
searching on/manipulating bookmark data.  This seems to explain all the effects
I observed above.  If I'm right, I think the summary needs to be changed.  How
about something like:
"bookmarks for same URL become synchronized, inherit/change one another's
properties"
(or we could say "...should not become synchronized...").  The point is that I
think the synchronization effects are part of this bug, and that "unable to have
2 ... bookmarks for same URL" is not sufficiently descriptive.
At least if people don't want to change the summary so late in the game, could
someone please confirm that the effects I describe belong in this bug report? 
Thanks :)

Comment 80

[Andrew Hagen]

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

Comment 81

[Cees T.]

A unique key for each bookmark would fix this, and would also make custom icons
a reality. If an extra attribute in bookmarks.html is too much work, perhaps
appending the bookmark title to the URL as ID and renaming/preventing the
addition of a bookmark with the same URL & title would be easier.

Either way would make fixing bug 10197 a snap too.

Comment 82

[mental]

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

Comment 83

[Gareth Randall]

Replying to: Additional Comment #57 From Ben Goodger 2002-03-18 20:02

If someone really has used the URL as the unique identifier in the bookmarks
database, then they have made the most fundamental error in database design:

1. In countless situations there will be duplicates. Do you think a bank should
index its customer database using their account balance as the unique identifier
"well, it's unlikely that two people would ever have exactly the same balance"

2. The decision on "should the user be allowed to have duplicate URLs" is not a
decision that some programmer should be taking. This should be left to the user.
I am fed up of being forced to do things an awkward way because an option should
have been left to the user to select, but wasn't.

So:

1. Read in the bookmarks and assign a sequential unique ID to each one. You
don't need a random generator (not that this saves much CPU) and you're going to
be storing the ordering elsewhere anyway.

2. Always use this unique ID internally. Hence, bookmarks can take any form they
like, and be as duplicated as they like.

3. Your database "meshing" should still work fine as long as it has been
designed well from the beginning. As you say that there will be problems,
presumably someone thought "well, let's assume we'll never get more than one URL
match", and designed the system along those lines? Please tell us that's not true...

(and apologies if this sounds too much like a flame)

Comment 84

[R.K.Aa.]

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

Comment 85

[Matthias Versen [:Matti]]

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

Comment 86

[Bill Mason]

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

Comment 87

[Boris Zbarsky [:bzbarsky]]

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

Comment 88

[Alfonso Martinez]

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

Comment 89

[Damir Perisa]

   most other browsers arent able to see, when a bookmark is twice set
   
   the easy solution should be: adding a second (or more) title(s) to each
   bookmark
  
   that is showed in the menus and the personal toolbar (most site-titles are
also   
   too long to be seen fully in the bookmark-menu, but in the sidebar, the full 
   title is ok)

Comment 90

[Bill Mason]

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

Comment 91

[Greg K.]

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

Comment 92

[Jeremy M. Dolan]

Since this is futured, a workaround (ie, simply preventing adding a second
bookmark) would be nice for 1.2, since the current consequences seem undefined,
occasionally even causing silent dataloss.

Comment 93

[Michael Moulton]

IMHO, banning duplicates is a terrible idea.  Most of us who use the Personal
Toolbar keep a duplicate of everything on it in our normal bookmarks file. 
Banning the duplicate would keep the toolbar from working right.

So far, the most logical solution mentioned has been to simply give each
bookmark a unique sequential ID when the bookmark file is read in (at startup),
and reindexing every time-- it wouldn't take that long, and it'd solve this
problem.

Comment 94

[m_mozilla]

my favorite reason for allowing multiple bookmarks:

put same bookmark under multiple keywords (especially custom keyword queries) so
that I can type whichever way I happen to be thinking about something. For
example, both "isbn" and "book" might be good keywords for an amazon.com search
and both "weather" and "forcast" might be good keywords for an accuweather.com
search.

I've also run into the "duplicates on PT" issue, but see that others have
already mentioned it in this bug.

-matt

Comment 95

[Rob North]

Some issues concerning properties, and duplicate bookmarks:

From looking at the properties, you'll have to associate most properties with
URLs, and some with individual bookmark entries. (Schedule and notify entries
are definitely URL specific, Info is defintiely bookmark specific.)

This suggests you'll end up with a table for URLs with bookmarks.
This table will be keyed by URL, and contain URL specific properties.

You'll also need a table for bookmark entries proper.
As mentioned in Comment #57 and Comment #83, the key must uniquely identify each
URL & bookamark-name pair.

If all properties are associated with bookmarks, then youll get 2 new bugs
appearing:
1. Excessive checking of URLs for updates, possibly once for each bookmark
referencing each a url.
2. Multiple notifications: Multiple alert boxes or Multiple windows opened for
same changed URL.

Once this bug is fixed, and if what I said above holds true, then
you might find the need to add to the properties dialog a tab containing all
other bookmarks that reference the url. (Probably should be posted as RFE)

Comment 96

[Ben Bucksch (:BenB)]

> Schedule and notify entries are definitely URL specific

No, they are not. I maybe want to have 2 schedules, to check each hour on
workdays and every 5 hours on the weekend.
I think the problem of multiple notification is neglectable or otherwise solvable.

Comment 97

[Thomas Berg]

I don't think it's worth to try to use the URL as a separate key/object.
That's because the URL in reality is just used as an address, not a "key" to the
information/data.
An example: I have a link to a page with algorithms expressed in REXX. 
Therefore I have a bookmark that's located in a map named "REXX".  But I have
also a bookmark in the map "Software" (as I can use the algorithm in another
language).  And maybe in a map "Algorithms".
(Note: In this example it's the same information that is used, but it can also
be the case that the page contains two or more independent informations.)

In the above case the bookmarks can be removed (one or more), have different
needs of notify, and the URL can be changed independently of each other (e g the
bookmark in "Algorithms" can be changed to a URL pointing to a better example of
the algorithm; or the original page has dissapeared and some bookmarks are
therefore removed while other is redirected to a new URL containing the
information relevent to that bookmark).

Of course You can use the duplication of the URL in efforts to enhance
performance/space constraints, or as a separate function to manage URL's as
such.  But that's not the main priority.

Comment 98

[Chris Lyon]

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

Comment 99

[David Tenser [:djst]]

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

Comment 100

[David Tenser [:djst]]

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

Comment 101

[Chris Lyon]

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

Comment 102

[HyperHacker]

Are any of the bookmarks' properties ever stored as individual files? If so then
that's why bugs occur when you have 2 with the same name - Most OSs don't allow
duplicate filenames in the same folder.

Comment 103

[Andrei Boros]

On comment #102: AFAIK all bookmarks go into a file "bookmarks.html" in the 
profile directory. The duplicate filename is not an issue in this case.

Comment 104

[Eric Krock]

Nominating for mozilla1.2 consideration. I count 27 DUPs of this bug and bug
174052 may become #28; that's one measure of the number of people this is
affecting. Another metric is the number of diverse symptoms this bug causes
(documented throughout all those DUPs). The presence of this issue frustrates
Mozilla bookmark users in many different ways; it seems that bookmarks will be
fundamentally broken at the core until it's resolved. Yes, changing the bookmark
architecture might introduce new bugs -- but look at all the bugs that are being
KEPT in the product by not fixing it! Surely the disease is worse than the cure
here?

Comment 105

[Paul Wyskoczka]

Removing - based on Eric nomination.

Comment 106

[Rob North]

As there seems to be some move to get this bug fixed, I'll comment
on replies to my suggestions

From comment #96
Yes, I hadn't considered this to be a useful feature.
Yes, multiple notifications for the same time could be solved quite easily. 
I could imagine the scheduler being able to do this (it might already do so).

From comment #97
I agree. There is no URL specific data.
I agree. The use of key/table for URLs is now only required to detect 
duplicate bookmarks, and aswer questions about duplicates.

Comment 107

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 108

[David Tenser [:djst]]

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

Comment 109

[Chris Lyon]

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

Comment 110

[Chris Lyon]

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

Comment 111

[Asa Dotzler [:asa]]

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

Comment 112

[Ben Tremblay]

I can't believe this is still dragging. 4.X works so well.
Isn't date created sufficiently unique? Why has this become such a major pain? 
(I can't /believe/ how bad bookmark performance is.)

Comment 113

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 114

[timeless]

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

Comment 115

[Michael Moulton]

I'm with Ben (Tremblay) on this one.  Bookmark performance is HORRID.  Since I 
switched from 4.x to Phoenix, my bookmarks have become completely out of 
control because I just can't deal with them the way I used to.  I'm going to 
have to dump them back into 4.x and organize them if nothing changes.

Comment 116

[Jan Varga [:janv]]

reassigning

Comment 117

[Pat Tressel]

Comment 113 by Brant Langer Gurganus hints that examples of dataloss are
needed.  I can provide some more...

After prolonged frustration and confusion over why bookmarks I've tried
to add simply failed to show up, and why added bookmarks would somehow
acquire the title belonging to another, and why some bookmarks would
simply vanish, and why I couldn't copy and paste a bookmark, and why
editing a bookmark seemed to provoke some (but not all) of these
weirdnesses, I just realized moments ago what must be happening
(confirmed in this bug report) -- the URL was being used as the primary
key.  I was attempting to bookmark search results from a library catalog,
but the bookmarks weren't being added.  Eventually I noticed that,
although the page titles were different, the URL displayed by the catalog
was always the same...

A search turned up this bug, and now, reading what the consequences are
of having multiple bookmarks with the same URL, I think I'm in trouble.
I'm going to have to find a copy of Netscape 4, and reconstruct what
I can of those bookmarks I know are affected by this problem.  Since I
have 17000 bookmarks, and I can't just "diff" my old and new files, this
is going to take quite a bit of time.  And that only helps for the
bookmarks prior to when I switched to mozilla (or rather, was compelled
to switch by the folks in charge of our computers...I didn't want to
switch because I'd already noticed the flakiness of the bookmarks).
That was about 4000 bookmarks ago...

For me, it's not a matter of being unable to shorten the names in my
Personal Toolbar (although I ran into that problem too, and had a vague
worry that the URL might be being used as a key, but said, naaah, they
wouldn't do that).

You see, I *do* make multiple copies of bookmarks, and edit them, and
put them in different folder hierarchies.  Or at least, I used to I've
still been going through the motions, but now I know that my alternate
copies have been either trashed or have vanished.  In other cases, I've
simply bookmarked the same site multiple times, independently.  Some of
the old copies of the bookmark had already been organized into appropriate
places in my folder hierarchy, and I'd come across the same site fo. r a
different purpose, and wanted to put the new bookmark in a new location
in my bookmark file.  With 17000 bookmarks, I don't remember in all cases
whether I've previously bookmarked a site, so I don't know whether what
I'm trying to add or edit is a duplicate.  I certainly don't know if the
site has altered the page title since I last bookmarked it.  So some of
these mysterious vanishing bookmarks have *also* been quietly nibbling
away at my *old* collections, that I thought were safe and stable.

Now for a more serious form of dataloss.  I don't just passively add
bookmarks.  I also add comments.  A large proportion of my bookmarks
are references to academic papers or research on subjects in my field.
I make (or made) repeated copies of these, to place in folders for
subtopics, or work of my own, to which they were relevant.  And in their
description fields, I put notes commenting on the work.

I've just done a (completely unnecessary) little experiment (but which I
felt I had to do to verify the problem):  I added a bookmark with a comment
in the description field.  Then, editing the bookmarks file by hand, I
made a copy of the bookmark (since mozilla wouldn't paste a copy).  In
the second bookmark, I changed the comment.  I brought up mozilla, saw
only one copy of the bookmark (the first), checked that (at that moment,
with mozilla still up) both bookmarks were still in the file, then exited
from mozilla.  Second bookmark went poof.

Note these both had identical titles and URLs.  (Note also that, contrary
to what some comments seem to imply, I was unable to create an exact
duplicate of a bookmark -- mozilla removed exact duplicates as well.)

Now, it seems likely, my other duplicates have vanished, along with my
notes.

I'm feeling a little sick...

In the hope of influencing any eventual fix, I'd like to second the remark
made by Gareth Randall (comment 83) that the key should *not* be the URL
but rather a unique ID.  As Gareth points out, use of a field that might
be duplicated as a key is something one is taught not to do within
the first week of a database architecture course.  Please *don't* take the
suggestion to conflate the URL with another data field (title or add date).
These together do not constitute something that is guaranteed unique.
(Certainly all three were identical in the case of my former duplicate
entries -- they differed only in their description).  At a company I used
to work for, that made use of massive and elaborate databases, it was
simply a rule that the primary key of any table should be a serial number,
not a data field.  It saved us from *much* trouble.  As an additional push,
consider that Oracle uses unique IDs internally for *everything*, even if
you specify some field as a key...

The standard procedure in a DBMS, if one wants to do fast searching on some
field or combination of fields, is to index them.  This is independent of
their use as keys.  You can still get fast lookups and searches even if
the actual key is a serial number.  If you want to do really fast matching
of just URLs, or some combination of fields, you can hash them.

Now I think I'll go off in a corner and whimper for a while...

Comment 118

[Cees T.]

ADD_DATE isn't guaranteed to be unique. Folders already have a unique ID. How
hard would it be use that instead of the URL?

OTOH, positions in the bookmark tree are unique. I'd use that. Though updating
that ID for all bookmarks in affected folders might take some time and could
cause problems when there are multiple open bookmark property windows while
moving bookmarks around. Then there's the option of randomly generating an ID
tag for a new bookmark on a per-folder basis.

Comment 119

[Michael Moulton]

Position in the tree?  There is NO sense in creating a key that has to change. 
The key of a bookmark should NEVER have to change.  Someone made the suggestion
a while back-- numbering the bookmarks.  First bookmark added = key 1, second =
2, third = 3, etc.  Honestly, I've yet to see a single advantage of the Mozilla
bookmarks system over 4.x... the whole thing is so slow I probably haven't even
tried all the features.  4.x brought my bookmarks file up in a few seconds, and
moving was virtually instantaneous.  With Mozilla, I'm lucky to get the
bookmarks window in 30 seconds, moving takes even longer, never mind creating
folders, organizing folders, etc.

Comment 120

[Cees T.]

On second thought, pointers are best. Leave the slow stuff for rarely used
things like searches.

Comment 121

[Pat Tressel]

Please listen to Michael Moulton!  "Position" actually *can't* be used as
a key, because it is not stable.  If you wanted (for whatever reason) to
maintain a positional numbering, and decided to make this number the key,
then inserting a new item would require updating O(n) items (n = number of
items in the bookmarks file).  This is not an operation supported by any
DBMS -- you'd have to do it by hand, changing items one at at time starting
at the last.

Also, the word "random" keeps cropping up.  Not only is there no need for
"random" IDs, but this is a bad idea, as a random choice may well collide
with a previous ID.  A serial number is simply a number that is incremented
each time a number is requested.  If the system is multi-threaded, the
function that provides the serial numbers should be synchronized.  If the
number rolls over, one can (for instance) take a bit of a time hit, and
compact the existing IDs down to the low end, or keep a freelist, or some
such thing.  If IDs are re-assigned each time the bookmarks file is read
in, then rollover isn't a real issue -- if someone has 2^64 bookmarks,
they're probably exceeded some other limit...

I realized that there's another thing I used to that died of the URL=key
problem:  I used to add bookmarks with no URL to serve as "headings" within
a series of bookmarks, when putting them in separate folders was less
convenient.  These were like separators, but with text.  I checked one of
the places in my bookmarks where I knew I'd put in this sort of "heading",
and they're all gone.

Comment 122

[Andrew Hagen]

Problems editing the keywords field in this bug. Attempting to delete all
keywords. Will add them all back.

Comment 123

[Andrew Hagen]

Adding all old keywords back.

Comment 124

[Chris Lyon]

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

Comment 125

[R.K.Aa.]

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

Comment 126

[R.K.Aa.]

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

Comment 127

[R.K.Aa.]

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

Comment 128

[Mason]

I note that this bug is marked nsbeta1+ which means it has been accepted for the
next Netscape release, right? Would that be 7.02? Will this bug be marked as
blocking1.3+ after 1.3b is released?

Comment 129

[Jan Varga [:janv]]

I'm going to work on this in near future (weeks).

Comment 130

[dirtyoldm]

Look above at "Additional Comment #121 From Pat Tressel  2003-01-26 20:30"

I have the same problem with the last several weeks' builds.
I also use bookmarks as dividers; if I change one of them, some of the others
change!

To reproduce:
Start with the stock default bookmarks.html.
Create a new bookmark "--- category ---" with URL "---"
Copy and paste into a couple of different bookmark folders.
Edit a copied one... one of the earlier ones changes to match.
Close and reopen Bookmarks... they are ALL changed.
Edit bookmarks.html with a byte editor and change one of the divider bookmarks.
Run Moz, go to Manage Bookmarks - the old text is back even after a reboot.
You can't kill it with a stick!

<rant> OHMYGOD just discovered it overwrote my real bookmarks when I tried to
change back!!!  Thankfully I have a backup.  Now it will take another hour
to figure out which stupid file to kill to use the real bookmarks.html
since there is NO 'Load new bookmark file'.

This is ridiculous.  Data is lost due to the same kind of M$-like complexity
as the braindead scheme to track emails; it will cause problems forever.
NS 4.x worked fine, stop worrying about tiny speed gains from major
complexity.  Pride goeth before a fall.  Wshew I feel better now!</rant>

Comment 131

[Jan Varga [:janv]]

and it won't be in 7.02, it will be in next major release

Comment 132

[Gareth Randall]

I'm glad to see that this has been targetted for 1.4alpha. Thankyou.

I was actually just checking this bug before dumping Mozilla and using something
else. If this target is honoured then I will remain a user and (hopefully)
future contributor.

I think questions have to be asked as to why such a fundamental gaffe was
allowed to sail past all the supposedly professional programmers working full
time on this, and in the 2.5 years this bug has been opened, almost no-one
actually did anything about it, and some posters to this bug report seem to have
come within a hairs-breadth of telling users that they should change their
working practices instead.

Sorry, but I personally have lost face because of this stupid programming when
trying to promote Mozilla, and this list shows that others have too.

Comment 133

[mozilla]

Wouldn't hold my breath.
This bug is still 'new'.  Nobody is responsible for it, it's not even 'accepted'.
Target?  Target for these bugs is always '2 releases away'.  Always will be.

Anyway, the only reason I never took IE up was because I hated needing 1 file
per bookmark and no separators.  Now I'm just wondering if anyone's written any
worthwhile competitors, but they all seem to be betas.

It's kind of strange that there is not a single good browser in the whole market
that is solid both internally and externally.  The only good thing I get out of
Mozilla is spam mail to my mail listed here.  Why is there so much put into the
mail program but nobody can bother to mask the mails listed in the bug reports?

Comment 134

[Adam Hauner]

> This bug is still 'new'.  Nobody is responsible for it, it's not even 
> 'accepted'.

Jan Varga took this bug several days ago and I hope that he really want to fix
(see nsbeta1+ keyword). This bug is blocked by bug 160019 and its asignee is out
of developing till 15th March. Please wait for fixing bug 160019 and don't add spam.

Comment 135

[Matthias Versen [:Matti]]

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

Comment 136

[Chris Petersen]

With the 2003-03-25-03 Macho (OS X) trunk and 2003-03-25-04 Win32 trunk , I 'm
not able to reproduce the original problem specified. Any one else still see
this with these builds ?

Comment 137

[Alex Bishop]

> With the 2003-03-25-03 Macho (OS X) trunk and 2003-03-25-04 Win32 trunk , I 'm
> not able to reproduce the original problem specified. Any one else still see
> this with these builds ?

I can't reproduce with 2003032508 on Windows XP. According to Bonsai, The
Bookmarks Branch was landed by Jan at 20:44 last night (bug 196756) so that
probably fixed it (along with a whole host of other problems).

Comment 138

[Tony Tovar]

There's no attachment assigned to this bug so where did this "Bookmarks branch"
come from?  Is this the "Phoenix backend Bookmarks rewrite" mentioned in the
March 19 mozilla.org meeting/notes,
http://www.mozillazine.org/articles/article3001.html ?

Comment 139

[Matt Brubeck (:mbrubeck)]

Re: comment 138 - Yes, see bug 196756.

Comment 140

[Chris Petersen]

Fixed by bug 196756. Verified.

Comment 141

[Jan Varga [:janv]]

Just for clarification, this bug was fixed on the bookmarks branch. This is not
a back port from Phoenix.

Comment 142

[Chris Petersen]

Verified

Comment 143

[brian]

As noted in bug 196756, this 'fix' broke Phoenix bookmarks completly - at least
on the 20030326 linux build.  No bookmarks show up and you cannot add/modify
bookmarks at all in Phoenix.

Comment 144

[Chris Lyon]

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

Comment 145

[Chris Casciano]

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

Comment 146

[Markus Multrus]

If this is fixed, someone should remove the relnote... :)

Comment 147

[Owen Marshall (Not reading bugmail)]

Comment 146 -- yes, you are correct =)

Pulled relnote from 1.4b AND base release notes. Removing RELNOTE keyword.
If this action was incorrect, please add a comment on bug 205479.

Comment 148

[Matthias Versen [:Matti]]

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

Comment 149

[Michael Moulton]

Just wanted to say thanks to the team for this one.  Got the new Firebird today
and this bookmark issue is gone as promised.  Beyond that, bookmark performance
as a whole is SIGNIFICANTLY improved over the older versions.

Comment 150

[Webmaster33]

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