Closed
Bug 27495
Opened 25 years ago
Closed 24 years ago
If bookmark folder is selected, new bookmarks should go inside
Categories
(SeaMonkey :: Bookmarks & History, defect, P2)
SeaMonkey
Bookmarks & History
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: rzach, Assigned: samir_bugzilla)
References
Details
(Whiteboard: Fix in hand)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
File | New Bookmark should create a new bookmark inside a folder, if one is
selected. If a folder is selected and you paste a bookmark, then the bookmark
should be filed inside the selected folder. Right now, there seems to be no way
to actually get bookmarks into a folder.
To reproduce:
1. Manage Bookmarks
2. Create new folder
3. Select folder
4. File | New Bookmark
Actual result: a new bookmark appears at the end of the bookmark list.
Expected result: the new bookmark should be filed inside the new folder.
5. Select new bookmark
6. Edit | Cut
7. Select new folder
8. Edit | Paste
Actual result: Bookmark reappears at end of list
Expected result: bookmark is moved into new folder
Linux build 2000.02.11.11
Comment 2•25 years ago
|
||
It appears that the same issue was already reported as bug 20073,
"Context menu should add item to selected folder", P2, M15.
OS: Linux → All
Hardware: PC → All
Comment 4•25 years ago
|
||
this is technically fixed. If you select a folder and paste or create a new bookmark, the bookmark will go inside.
I contend that this is wrong and should only be the case when the folder is open/expanded because now you can't create/paste
below the folder, but rjc disagrees with me and that is the subject of bug 28853.
I'm going to mark this fixed and verified
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 6•25 years ago
|
||
> If you select a folder and paste or create a new bookmark, the bookmark will
> go inside.
I don't see that happening. When I select a folder (it's a folder inside my
personal toolbar folder), and create a new bookmark, the new bookmark becomes a
peer of the folder, not a child. Reopening the bug. (I'm using 2000-02-23-08 on NT)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 7•25 years ago
|
||
My bad.
As it turns out some more careful QA shows us that the behavior is different for paste vs. create new bookmark. cc'ing rjc as I
believe it's his code that fixed the paste as peer(instead of nesting) bug so this would be the same thing except it's create
instead.
Comment 9•24 years ago
|
||
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
Assignee: slamm → ben
Status: REOPENED → NEW
Comment 10•24 years ago
|
||
*** Bug 59946 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
*** Bug 59946 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
Ben, please take a look at this patch so it doesn't get lost.
Comment 14•24 years ago
|
||
Netscape Nav Triage Team: adding german to the cc list - we need UE help.
Keywords: nsbeta1
Comment 15•24 years ago
|
||
*** Bug 59948 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Priority: P3 → P1
Comment 16•24 years ago
|
||
If this was fixed, with the current UI there would be no way to create a new item
at the top level in a window where the only current top-level items were folders,
and where the list of folders was larger than the window -- because there would
always be a folder selected, and there would be no way to deselect it without
selecting another one.
That problem could be fixed in any of three ways:
(1) only make new bookmarks go into the selected folder if the folder is
expanded;
(2) implement drag-selection of multiple tree items (bug 48912), which would
require that tree items would be deselected if the user moused down outside
the actual text of the item (but even that wouldn't work for people who
couldn't use a pointing device);
(3) return 4.x's `Bookmarks for Jane Doe' root folder to Seamonkey's bookmarks
window (as I suggested in bug 28853), so the user could select the top-level
folder in order for new items to go at the top level.
Comment 17•24 years ago
|
||
I like (3), mpt do you want to file an RFE for it?
Comment 18•24 years ago
|
||
(3) works for me too, and is analogous to the organization of mail folders.
Comment 19•24 years ago
|
||
Ugh. I suck. Sorry for letting this one sit so long, guys.
I need the nsBookmarksService.cpp part of this patch now, as I'm rewriting the
bookmarks window and want this functionality. The js code for the bookmarks
window has mostly changed in my tree however so I'll rework your js to make it
work with my code.
As for mpt's comments, yes I believe there should be a root folder. After I'm
done with my core bookmarks tasks, I'm going to investigate this. btw: after my
bookmarks checkin dragging of multiple items will be possible again.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8
Comment 20•24 years ago
|
||
(3) was long ago suggested and solves a number of other problems as well. There is an
RFE or bug floating around in bugzilla somewhere asking for a root bookmarks folder.
Comment 21•24 years ago
|
||
Bug 36339 : bookmark manager needs a root level. (That's marked as WONTFIX
though...)
Comment 22•24 years ago
|
||
(3) is the most sensible way for me as well
Comment 23•24 years ago
|
||
Patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 24•24 years ago
|
||
for pete's sake, now with a 2001041004 build on Win98, if I File|New Bookmark with a
closed folder selected and enter a name and location in the dialog and just click 'OK'
the new bookmark is created inside the folder as the last child.
However, if I cut a bookmark and selecta closed folder context menu-->paste results
in the bookmark being pasted below the folder as a peer. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 25•24 years ago
|
||
nav triage: downgrading to P2, paul wants to take this bug so reassigning to
him.
Assignee | ||
Comment 26•24 years ago
|
||
Assignee | ||
Comment 27•24 years ago
|
||
pchen, please r.
alecf, please sr.
Thanks!
Assignee: pchen → sgehani
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Whiteboard: Fix in hand
Comment 28•24 years ago
|
||
coolness. sr=alecf
Comment 29•24 years ago
|
||
Samir, you stud you! r=pchen
Assignee | ||
Comment 30•24 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 31•24 years ago
|
||
samir's patch fixes the last remaining issue in this bug - namely that creating a new bookmark
with a folder selected now creates the bookmark inside that folder.
I'm marking this VERIFIED Fixed with 2001050403 builds even though i still contend that this
approach is all wrong.
I still believe pasting/creating onto a closed folder should paste/create as peer and on an
open folder should paste/create as child. In this way we maintain all the same abilities w/o
relying on D&D. With the current setup one can _never_ place a bookmark between two folders
without using D&D.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 32•24 years ago
|
||
"However, if I cut a bookmark and selecta closed folder context menu-->paste
results in the bookmark being pasted below the folder as a peer. Reopening."
Claudius,
I may have misinterpreted your comments above which sounded like context menu
paste was the erroneous behavior. Were you suggesting that File|New Bookmarks
behavior should be like context menu paste instead of the other way around? It
was not clear to me. If this is correct and per the spec then I can change the
behavior accordingly. Please help me understand the issue by clarifying as I
ramp up on this part of the product. Thanks.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•