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.

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.

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

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?

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

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

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.

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.

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

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.

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

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.

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.

see also bug 46686, which may be related somehow

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

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

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

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

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

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.

Additional Comments From timeless@bemail.org 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

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

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.

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

Crash is propably a dup of bug 46686.

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.

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.

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

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

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

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

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>

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

.9

nav triage team: Futured to make room on Ben's plate for 41888

nav triage team: Forgot to bump down priority to p4

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

nav triage team: Not going to happen for beta, marking nsbeta1-

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

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

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

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

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

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

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

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

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

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 claudius@netscape.com's assessment of the problem in comment #32, that this "is a fundamental flaw".

mass reassign of pchen bookmark bugs to ben

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

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.

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

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

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

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.

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.

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.

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

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

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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?

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

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.

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)

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

Tony Tovar: fill new bug report with port issue.

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

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

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 :)

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

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.

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

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)

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

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

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

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

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

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)

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

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

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.

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.

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

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)

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

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.

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

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

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

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

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.

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.

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?

Removing - based on Eric nomination.

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.

Nav triage team: nsbeta1+/adt2

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

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

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

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

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

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.

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

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.

reassigning

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

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.

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.

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

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.

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

Adding all old keywords back.

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

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

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

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

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?

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

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>

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

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.

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?

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

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

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 ?

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

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 ?

Re: comment 138 - Yes, see bug 196756.

Fixed by bug 196756. Verified.

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

Verified

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.

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

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

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

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.

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

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.

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