Closed
Bug 789468
Opened 12 years ago
Closed 9 years ago
Impossible to add new bookmark for URl already bookmarked via menu 'Bookmarks → Bookmark this Page' or shortcut <shift+control+d>.
Categories
(SeaMonkey :: Bookmarks & History, defect)
SeaMonkey
Bookmarks & History
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: dsb, Unassigned)
References
Details
(Whiteboard: INVALID? Working as Designed.)
Attachments
(2 files)
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
Whiteboard: WONTFIX?
Version: SeaMonkey 2.12 Branch → Trunk
Comment 3•12 years ago
|
||
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
Comment 6•12 years ago
|
||
> 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
moz_bookmarks
id: unique
fk: multiples allowed, all pointing back to the same (unique) id: in moz_places
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?)
Comment 10•12 years ago
|
||
(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?
Comment 11•9 years ago
|
||
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
Closed: 9 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>.
Comment 12•9 years ago
|
||
((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
Updated•9 years ago
|
Reporter | ||
Comment 13•9 years ago
|
||
> 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 → ---
Updated•9 years ago
|
Comment 14•9 years ago
|
||
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.
Reporter | ||
Comment 15•9 years ago
|
||
> 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>.)
Comment 16•9 years ago
|
||
Resolution due to comment above!
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•