Closed Bug 151706 Opened 22 years ago Closed 20 years ago

copying and pasting bookmarks produces odd results when bookmarks are moved or copied

Categories

(SeaMonkey :: Bookmarks & History, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sayler, Assigned: p_ch)

References

Details

Attachments

(1 file)

If you use the Bookmark Manager to create a bookmark by copy, and then move one
of the resulting bookmarks around, it affects the location of the original.

To reproduce:
. Create a bookmark to mozilla.org from inside the manager (file > new > bookmark)
. right click on the bookmark, and click copy
. if needed create a new folder
. right click on a folder and click paste.  You should have an exact copy of the
bookmark in the new folder.
. Drag the copied bookmark outside of the new folder (not even into the place
where the old one was).  The original bookmark moves up a level as well.

I can also get bookmarks to disappear this way (and in such a way that pasting
bookmarks into the disappeared location causes them not to appear.

Looks like copying bookmarks is done as a pointer-like operation and maybe that
when moving things ther is a search done as well on the list?  Just a guess.
In trunk Build ID: 2002062713 copy does not work in Bookmarks Manager.
Copy now works. Confirming on 1.1 alpha trunk 2002070204 Windows 98.

Something is definitely wrong here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
taking
Assignee: ben → chanial
Depends on: 160019
I have seen two more symptoms of what I believe to be the same core issue
(handling copied bookmarks as a pointer rather than as independent objects): 
1) If you copy a bookmark, paste it, and then change the name of the copy, the
name of the original is changed as well. Likewise, if you change the name of the
original, the name of the copy is changed as well.
2) Stranger still: if, as an attempted workaround, I delete the copied bookmark,
then create a new one in the same place, and give it a new name, but point it at
the same URL as a previously-created-then-deleted bookmark, after I hit "OK" on
the dialog, the new bookmark shows up having the previous name! This suggests
that internally, there's some kind of index/hash table of the bookmarks by URL,
and if you make two bookmarks to the same URL, they wind up with a single object.

Believe it not, there are actually good reasons to have two bookmarks to the
same URL, especially temporarily. I have hierarchical nested folders of bookmark
to Bugzilla queries broken down by product/release/<list of bookmarks: nominees,
approved, future, etc.>. When we start planning a new release, I create a new
folder and want to populate it with bookmarks by copying the bookmarks from the
previous release's folder over, then editing them to point at the new release
keyword. But I can't do this because of this bug!

Let me know if you want me to open separate bug reports on those symptoms, but
since they appear to be symptoms of the same underlying problem as this bug
report, leaving them inline for now. Appending "or copied" to Summary to help
other sufferers of the same problem find this report. 

Nom. mozilla1.2. This really fouls up power bookmark users.
Summary: copying and pasting bookmarks produces odd results when bookmarks are moved → copying and pasting bookmarks produces odd results when bookmarks are moved or copied
Eric, you're describing symptoms of bug 51683.
Thanks for the heads-up. I had already filed bug 174052, "night of the living
dead bookmark name (create bookmark, delete, create new with different name, get
old name)," but it may wind up being considered the latest DUP of bug 51683.
This works for me; probably fixed in the 2003 bookmarks rewrite. Does anybody
still see this?
Boying, this bug was fixed in moz1.4, could you please open a new bug and
describe what issue your patch is addressing?
Fixed now, assuming: by the big bookmarks rewrite last year.
Resolving.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: