Closed Bug 36339 Opened 24 years ago Closed 21 years ago

[FIX] bookmark manager needs a root level

Categories

(SeaMonkey :: Bookmarks & History, defect, P3)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4alpha

People

(Reporter: poletti, Assigned: p_ch)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file, 1 obsolete file)

Patch v2.0
17.11 KB, patch
Details | Diff | Splinter Review 
Within the bookmark manager and the bookmark sidebar there is no
"root" level. This make it impossible to paste a URL to the
root level.

I beleive this is an important need because imported IE bookmarks
can not be dragged to a different location. They can be highlighted
and copied but then must be pasted to a sub directory. They can not
be pasted to the root.
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
UI, over to german for a look.
Assignee: slamm → german
Summary: bookmark manager usability → bookmark manager needs a root level
Agree we need to have a root bookmarks to drop into. I was assuming that would be 
the container/window/panel as a target for those cases where users are not 
dragging into a folder. 4.x had a root "Bookmarks for FirstName.LastName". As for 
copy paste I was assuming that if no folder is opened/selected it would 
automatically get added to the root.
Severity: normal → minor
Status: NEW → ASSIGNED
Target Milestone: --- → M18
This will also help with bug 20124 (d and d feedback when sorted) which is 
somewhat related. assigning back to mcafee.
Assignee: german → mcafee
Status: ASSIGNED → NEW
is this bug dead?  still an issue in build 2000102404 for win98.

still cannot paste bookmarks into the main menu - for example, copying bookmarks
out of folders and into the main bookmark menu, for ease of use.

well past original target - a new one is needed.  suggest upping this to at
least normal severity.



Netscape Nav triage team: this is not a Netscape beta stopper. marking wontfix
Status: NEW → RESOLVED
Closed: 24 years ago
Keywords: nsbeta1-
Resolution: --- → WONTFIX
knous@netscape.com, please do not wontfix bugs which you are not the owner for, 
unless you have permission from the owner to do so (and state that in the bug). 
Unlike bug 47802, I'm certain you don't have permission from the module owner to 
wontfix this bug, because he said in bug 27495 that bookmarks *do* need a root 
folder.

Asa, this is the second time this has happened on bugs I've seen, and there are 
probably others; I suggest checking all bugs which knous@netscape.com has 
resolved as wontfix or invalid (I don't know how to query for that in Bugzilla).
Status: RESOLVED → REOPENED
Hardware: PC → All
Resolution: WONTFIX → ---
Reassigning to Ben.
Assignee: mcafee → ben
Status: REOPENED → NEW
yup.
Status: NEW → ASSIGNED
Ben, please reconsider milestone; currently it's M18.
the most recent bookmarks i've seen included a root level.

it looks like this fixed it:
mozilla/xpfe/components/bookmarks/resources/bookmarks.js rev 1.88 
<ben@netscape.com> 04 Feb 2001 23:32 Bookmarks Window Updates, includes fixes 
for 27495, 38004, 42080, 43146, 43753, 47494, 50835, 53403, 55447, 55448, 55787 
r=blake, a=hyatt
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Target Milestone: M18 → mozilla0.8
This seems to have regressed.  See bug 90009.
Testing in 9.2 this is not resolved.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.8 → mozilla1.1
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
Blocks: 36318
Adding access keyword.  Mouse users can drag-and-drop to toss a bookmark into 
the root level, but keyboard users have to use copy/paste.
Keywords: access
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
Would this block bug 141227?
*** Bug 68625 has been marked as a duplicate of this bug. ***
Blocks: 113666
Is this bug asking for an actual root folder - or just a way of saying "don't
use a folder" when looking at the Add Bookmark dialogue?  I've opened bug 158648
which, based on an answer to this, may or may not be a duplicate.  (Note that
File Bookmark... defaults to root.)
It probably will need to be an "actual folder" because users should be able to
see, drag-to, and select the root folder. Currently, the root folder is not
*discoverable*

IIRC NC4 had a pretty clear way of handling this.
taking, I have a fix.
Assignee: ben → pierrechanial
Status: NEW → ASSIGNED
Attached patch Patch v1.0 (obsolete) — — Splinter Review 
This patch sets a NC:BookmarksTopRoot resource on top of NC:BookmarksRoot.
It sets the ref to the former for the bookmark manager and the folder picker
and leave the latter for the bookmark sidebar tab to save space (same as IE)
I changed the tab indentation, because the majority of the checkins in
nsBookmarksService.cpp using space used tab=2 spaces.
More front-end polishing will be done in forthcoming patch to correctly handle
the two top resources.
r/sr please.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
iirc root classically was "Bookmarks for <...>", i'd expect that a correct fix
would restore that behavior...  I've asked pch to read through the old root
bugs, and I'll spend a bit of time reading over the history to find out about
the most recent regression.

for reference, filing contrary bugs is not really a useful tactic.
FWIW, I think that filing contrary bugs is perfectly acceptable so long as when
resolving any one of them (and marking the remainders as INVALID after that one
is fixed) offers a better solution than to what is currently in place. 
Whichever bug gets the most interest, majority acceptance, and gets a patch
checked in soonest, can be the "winner" - just as with any other business-level
competitive practice.
Summary: bookmark manager needs a root level → [FIX] bookmark manager needs a root level
Attached patch Patch v2.0 — — Splinter Review 
New patch that names the root bookmark folder the following way:
- if #profile>1 "Bookmarks for xxx"
- if #profile=1 and is 'Default': "Bookmarks" otherwise: "Bookmarks for xxx"
I removed the useless mPersonalToolbarName in the parser class and set the
title of the bookmark manager to... well... "Bookmark Manager"
I did not found an old bug that would deal about a pb with the root folder
Attachment #93780 - Attachment is obsolete: true
I believe the patch keyword is appropriate here...
Keywords: patch
ok, I have now tested this patch on windows, and it compiled fine; also,
importing of MSIE bookmarks worked well.
Blocks: 76631
Blocks: 48820
Blocks: 170994
What's the current state of this bug? It has a patch and the last comment was
made in August 2002. Is the patch still working and should it be checked in for
1.3b?
Blocks: 196756
Target Milestone: mozilla1.2alpha → mozilla1.4alpha
The bookmarks branch has landed.
Fixed.

really fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → FIXED
Verified in the 2003-03-25-03 Mach-o OS X trunk and 2003-03-26-04 Win32 trunk
builds.
Status: RESOLVED → VERIFIED
I don't know if I should file this as a sep bug (I'll let you decide), but if I
go into the bookmark manager and try to delete the root folder (bookmarks) it
renders that instance of the bookmark manager unusable.  I can no longer delete
or visit any of my bookmarks.

Bookmarks is deletable, but Personal Toolbar Folder is not.

win2k 2003032608
Re: Comment #32
It will be fixed by my patch for bug 205378
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: