Closed
Bug 36339
Opened 25 years ago
Closed 22 years ago
[FIX] bookmark manager needs a root level
Categories
(SeaMonkey :: Bookmarks & History, defect, P3)
SeaMonkey
Bookmarks & History
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.4alpha
People
(Reporter: poletti, Assigned: p_ch)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file, 1 obsolete file)
(deleted),
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.
Comment 2•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
Netscape Nav triage team: this is not a Netscape beta stopper. marking wontfix
Comment 7•24 years ago
|
||
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 → ---
Comment 10•24 years ago
|
||
Ben, please reconsider milestone; currently it's M18.
Comment 11•24 years ago
|
||
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
Comment 12•23 years ago
|
||
This seems to have regressed. See bug 90009.
Comment 13•23 years ago
|
||
Testing in 9.2 this is not resolved.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.8 → mozilla1.1
Comment 14•23 years ago
|
||
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
Comment 15•23 years ago
|
||
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
Comment 17•22 years ago
|
||
Would this block bug 141227?
Comment 18•22 years ago
|
||
*** Bug 68625 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
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.)
Comment 20•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 22•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Comment 23•22 years ago
|
||
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.
Comment 24•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Summary: bookmark manager needs a root level → [FIX] bookmark manager needs a root level
Assignee | ||
Comment 25•22 years ago
|
||
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
Comment 27•22 years ago
|
||
ok, I have now tested this patch on windows, and it compiled fine; also,
importing of MSIE bookmarks worked well.
Comment 28•22 years ago
|
||
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?
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.4alpha
Comment 29•22 years ago
|
||
The bookmarks branch has landed.
Fixed.
Comment 30•22 years ago
|
||
really fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
Comment 31•22 years ago
|
||
Verified in the 2003-03-25-03 Mach-o OS X trunk and 2003-03-26-04 Win32 trunk
builds.
Status: RESOLVED → VERIFIED
Comment 32•22 years ago
|
||
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
Comment 33•21 years ago
|
||
Re: Comment #32
It will be fixed by my patch for bug 205378
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•