User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120826 Firefox/15.0 SeaMonkey/2.12 Build ID: 20120826214753 Steps to reproduce: I tried to add a bookmark for the current page (using the "Bookmark this page" menu item of the "Bookmarks" menu), when displaying a page for which a bookmark existed. (I tried to (temporarily) record the URIs of a couple of pages I was looking at and wanted to come back to, by adding a bookmark for each one. I also tried bookmarking one twice, to have a duplicate, adjacent bookmark to remind me about that particular page. Then I closed my tabs.) Actual results: Nothing happened for some bookmark-add attempts. In particular, no new bookmark appeared where new bookmarks usually appear (in the tree in the Bookmarks Manager window). (The information I thought I had saved in the bookmarks list (and that was saved in previous versions of SeaMonkey (and all the way back to Netscape 4)), was _not_ saved in the bookmarks list.) Expected results: SeaMonkey should have added a new bookmark regardless of whether another bookmark for the same URI existed (and regardless of where in the bookmarks tree the other was). Obviously, SeaMonkey should not prevent the user from adding multiple bookmarks for the same page. (If you couldn't have duplicate bookmarks for the same page in two different bookmark folders, SeaMonkey would be seriously broken.) However, SeaMonkey also should not prevent the user from adding such bookmarks easily (using the usually "Bookmark this page" command). If this change in behavior was intentional, to, say, add a feature to avoid _accidental_ duplicate bookmarks, then the design of the feature needs to be adjusted. At a minimum, SeaMonkey should warn the the user that it is failing to add the requested bookmark (by default, until the user turns of the warning).
Present on trunk, but I'm not sure that this is not intended behavior.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Version: SeaMonkey 2.12 Branch → Trunk
You should be able to have two or more bookmarks for the same page as long as they are in different folders. You shouldn't be able to have two bookmarks to the same page in the same bookmark folder.
Confirmed. And agreed, with Daniel, that is. No reason you should not be allowed to add dup's. I want to. And I do all the time. While /Bookmark This Page, Ctrl+Shift+D/, which I can't say I use or else I would have run into this ages ago, won't allow dups, /File Bookmark, Ctrl+D/ does. So in my case, unless I specifically want to change something, my bookmark "procedure" is automatically, Ctrl+D+Return.
> You shouldn't be able to have two bookmarks to the same page in the same bookmark folder. Why the heck not? This is not a file system where things are accessed by name and therefore have to have unique names. Daniel
> This is not a file system where things are accessed by name and therefore > have to have unique names. But this is a RDBMS with a normalized schema which means that each unique url is stored once in the database although it may appear in multiple locations in the bookmarks tree, but not twice in a particular folder. This is by design.
Whiteboard: WONTFIX? → INVALID? Working as Designed.
It looks like moz_bookmarks has an id:, which is unique 1:1. The other fields are not. The fk: field in moz_bookmarks refers back to moz_places id: field, which is unique 1:N. But the fk: field is not, allowing N:1. So you can have multiple bookmarks in moz_bookmarks, all with the same fk:, so all pointing to the same id: in moz_places, so all having the same URL. https://wiki.mozilla.org/images/0/08/Places.sqlite.schema.pdf http://stackoverflow.com/questions/464516/firefox-bookmarks-sqlite-structure
Created attachment 659577 [details] Screenshot. moz_bookmarks id: unique fk: multiples allowed, all pointing back to the same (unique) id: in moz_places
Created attachment 659579 [details] Screenshot. moz_places id: unique (1:N) one id: pointing to a url: referenced by the fk: field in moz_bookmarks (potentially many times) --- Note that I was able to "generate" an "http://gena01.com/" URL by typing said URL into the address bar. Now even though "gena01.com" rolled over to & displayed as "www.gena01.com", bookmarking that "page" did generate the "http://gena01.com/" URL. I would think that entry, id: 28, will end up being an albatross, always there, never being able to be referenced nor deleted? (Actually it looks like entries once put into moz_places are perpetual?)
(In reply to Philip Chee from comment #6) > > This is not a file system where things are accessed by name and therefore > > have to have unique names. > But this is a RDBMS with a normalized schema which means that each unique > url is stored once in the database although it may appear in multiple > locations in the bookmarks tree, but not twice in a particular folder. This > is by design. Hm, I can make a single URL appear any number of times, even in a single folder, by using Copy and Paste in the Bookmarks Manager. Or is your "bookmarks tree" something else than the tree displayed by the Bookmarks Manager?
Definitively not NEW, but in discussion - and more or less rejected. As Tony states many users (like me) have been used to have particular bookmarks at several places several times. That can be done easily by drag and drop with mouse or menu 'Bookmarks → File Bookmark ...'. That's useful intended behavior. But menu 'Bookmarks → Bookmark this Page' or shortcut <shift+control+d> simply will add a bookmark at the end of the list. Adding a clone of a bookmark to the end of the list seems to be rather useless, I can't imagine any real life scenario for what that should be needed. So as result of discussion and consideration above I close this one WONTFIX @reporter: Please feel free to reopen this one if you can contribute really good, comprehensible arguments that the requested behavior might be useful for particular applications. Your arguments in Descriptions are not comprehensible (You can simply create a
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Summary: SeaMonkey fails to add new bookmark if URl already bookmarked → Impossible to add new bookmark for URl already bookmarked via menu 'Bookmarks → Bookmark this Page' or shortcut <shift+control+d>.
((oops)) @reporter: Please feel free to reopen this one if you can contribute really good, comprehensible arguments that the requested behavior might be useful for particular applications. Your arguments in Descriptions are not comprehensible, we can't see a general benefit of requested behavior
> But menu 'Bookmarks → Bookmark this Page' or shortcut <shift+control+d> simply will add a bookmark at > the end of the list. No. If another bookmark for the same URL already exists in the bookmark tree, it will _not_ add a bookmark at the end of the list. > Adding a clone of a bookmark to the end of the list seems to be rather useless, I > can't imagine any real life scenario for what that should be needed. How about this real life scenario which was useful (to me, even if you never work this way) and which used to work fine before SeaMonkey's behavior was changed: I'm browsing around and want to quickly "drop" (create) some bookmarks in order to note the set of relevant pages or links that I encountered in this episode of browsing, and that I want to come back to (right away or later) in order to take another look at them and whose bookmarks I want to then file for real or just delete. (Sometimes I'd even drop two adjacent temporary bookmarks as a reminder that something's special.) I use the simplest, quickest way to create the bookmarks (using whichever bookmarking command just added the bookmark to the default bookmarks folder without even prompting, or using one that popped up a dialog box but then not changing the selected folder in the control in the dialog). Before SeaMonkey's behavior was broken relative to this, if I had used "Bookmark this page ..." or "Bookmark this link ..." (without filing in a non-default folder) say, 10, times to try to note 10 pages or links, I would have 10 bookmarks adjacent to each other at the (current) end of the default bookmarks folder. That is, my temporary "recording" of my set (list) of 10 things to check out was always intact. Specifically, it didn't matter whether any of the 10 URLs I tried to bookmark already had bookmarks elsewhere (whether in the same folder or somewhere else in the overall tree of bookmarks). Now, with the breakage, I _might_or_might_not_ have that list of 10 bookmarks at the end of the default bookmarks folder--it depends on which other bookmarks exist in my tree (whether any others have one of the same URLs). So now the scenario that I used for years no longer works. (Yes, it's possible to get the wanted 10 new bookmarks next to each other in whatever folder, but it now takes a lot more thought and time (e.g., checking whether Bookmarks . Bookmark This page created a bookmark or not, or checking whether context-menu Bookmark... command gave a "New Bookmark" or an "Edit Bookmark" pop-up, and then working around the second cases somehow)--when the whole point was to quickly record something so I could come back later when I had more time.) Hmm... (Some) SeaMonkey developers took away and refuse to restore the version of Find Bookmarks that "navigated" the GUI to the location of a found bookmark in the bookmarks tree (and thereby allowed immediate viewing of and operations on the context of the found bookmark) that (some) old (and new?) users want. I wonder if there's a lack of understanding or awareness that it's not just the _content_ of a bookmark (URL, name, tags, whatever) that is important and _carries_ _information_, but it's also the bookmark's _location_. Note that bookmark's location information is not just which folder it is in, but also where it appears relative to sibling items. (In case that's not obvious, consider organizing a folder with the most, say, important bookmarks at the beginning and less-important ones at the end. Or just consider putting in separators--moving them around would erase information (the user's grouping of bookmarks).) (Whoever created the current bookmarks search provided only the internal bookmark information, not even listing the name of the containing folder, let alone giving direct GUI access to the bookmark in the tree folder. That also means that you can't search for a bookmark that you know is in a folder with related bookmarks in order to get to those related bookmarks. Yes, if you use tagging you don't need that as much, but you still need to get to the folder if you want to rearrange the bookmarks currently in the folder that know bookmark.) Note how my scenario _also_ uses the information in the _location_ of the bookmark, not just the information "inside" it or a seeming duplicate-- I want a new bookmark at the _end_ (part of location) of the default bookmarks folder (part of location). Even if I already have another bookmark with the same internal information (e.g., URL, etc), that other bookmark is not really a duplicate because it doesn't have the same _location_ information. Reopening, hoping yet again that the "breakage" (okay, change in behavior) will get fixed.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I did some additional research. a) With a SM 2.0.0 the behavior indeed was different, ˋ<shift+control+d><shift+control+d><shift+control+d><shift+control+d>ˊ added 4 bookmarks for the currently visible page. b) 2.8 already has current behavior (no twins added) c) reporter's goal still can be reached with ˋ<control+d><enter>ˊ, what will add a bookmark independent whether a bookmark for this page does already exist or not. c1) I don't think that ˋ<control+d><enter>ˊ is unacceptable additional effort compared to ˋ<shift+control+d>ˊ d) reporter states that HE was used to use ˋ<control+d><enter>ˊ to reach his goal, but he did not state why any users also might be pining for old behavior. 0 Votes within nearby 4 years seem to indicate that there are not many congenial users. e) may be root of the changed behavior was a changedin FF/Core? @IAN, @Karsten: Currently "Bookmarks and History" is without owner or peers, so can one of you please leave a statement whether you see reasons to follow reporter's request? Without comments from your side I will mar this one WONTFIX again.
> c) reporter's goal still can be reached with ˋ<control+d><enter>ˊ, [which] will > add a bookmark independent whether a bookmark for this page does already > exist or not. Yes, that seems to work to reliably (independent of other bookmarks) add bookmarks for _pages_ (as opposed to for _links_). Note that bookmarking a link doesn't seem to have a corresponding option. Also, I notice that Bookmark This Link... is inconsistent with Bookmark This Page...: - With the <page context menu> . Bookmark This Page... command, for both the case of showing a new bookmark or showing an already-existing bookmark, the corresponding pop-up boxes (labeled "Page Bookmarked" and "Edit this Bookmark") are almost the same, with both letting you see and presumably change the folder. Also, both boxes let you end up without the bookmark--the former has "Cancel", and the latter has "Remove Bookmark".) - However, the <link context menu> . Bookmark This Link... command works inconsistently compared to the above: For the case of adding a new bookmarks, it seems to be (almost*) the same: You get a pop-up labeled "New Bookmark" that lets you see and change the folder. (*It's a separate window (I see window manager window decorations) rather than what Bookmark This Page... uses. Did some intended changeover get dropped?) However, for the case of editing an existing bookmark, things are not consistent: You get a 'Properties for "..."' pop-up (separate window) that does _not_ have any "Remove Bookmark" button AND that does _not_ show or let you change the containing folder (and that does have UI components for fields/properties that the other pop-ups don't have). (That UI inconsistency should be fixed. Hmm. That last pop-up is similar to the "New Bookmark" pop-up that results from control-D. So control-D does some kind of "Add Bookmark" without checking for supposed duplicates, and "Bookmark This Page" and "Bookmark This Page..." do some kind of add-or-edit-depending command? > c1) I don't think that ˋ<control+d><enter>ˊ is unacceptable additional effort > compared to ˋ<shift+control+d>ˊ Yes, I guess that's fine. (Actually, <control+d><enter> is probably easier than <shift+control+d>.)
Resolution due to comment above!
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago → 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.