[SM] add folder column so bookmark search results shows where bookmark is in folder hierarchy

ASSIGNED
Assigned to

Status

defect
P2
normal
ASSIGNED
19 years ago
7 months ago

People

(Reporter: andre.jonsson, Assigned: ben)

Tracking

({helpwanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [2012 Fall Equinox])

Attachments

(2 attachments)

From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.17-0.24mdk i686)
BuildID:    2000101015

When searching bookmarks it doesn't say where the found bookmarks are located,
under which (sub)folder.



Reproducible: Always
Steps to Reproduce:
1. Open bookmark search window, from either browser window or manage bookmarks
window.
2. Enter e.g. 'a' in the search field, press 'Find'.



Actual Results:  The shown search hits only show the normal bookmark
information, i.e. Name, URL, Custom Keyword and Description.

Expected Results:  I think there should be some indication of where the bookmark
is located in the (sometimes very big) bookmark tree, or a 'go to bookmark'
button, which will open the bookmarks window (it not open) and open the
apropriate bookmark folder and highlight the bookmark in question.
Confirming. I see this as a good RFE. Basically list the bookmarks' position in the BM
hierarchy and/or provide a button to reveal it(show it selected) in the Manage Bookmarks window
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: bookmark search results doesn't show where bookmark is → [RFE]bookmark search results doesn't show where bookmark is
Netscape Nav triage team: this is a Netscape beta stopper.  adding german to the 
cc list. Could use some UE help on this one.
Keywords: nsbeta1
Priority: P3 → P2
Easy. Just do what Sherlock does. In the Search Results window, have two panes; 
one which lists the results, and one which shows the parent folders (with 
cascading indention) of the currently selected result.
nav triage team:

Nice but don't think we have time for beta1, marking nsbeta1-
Keywords: nsbeta1nsbeta1-
*** Bug 63827 has been marked as a duplicate of this bug. ***
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
*** Bug 83342 has been marked as a duplicate of this bug. ***
URL: n/a
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
*** Bug 114604 has been marked as a duplicate of this bug. ***
*** Bug 114779 has been marked as a duplicate of this bug. ***
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
How about an 'Open Containing Folder' menu item (like Windows Explorer), which
would open the bookmark tree down to the folder containing bookmark then select
the bookmark?

At the moment I have to use a text editor and search bookmarks.html to find out
where something is, which is a bit pants really.
*** Bug 134219 has been marked as a duplicate of this bug. ***
Please add 'find' to summary so the obvious search for "bookmark find" will include
this bug report.  Thanks...
*** Bug 135213 has been marked as a duplicate of this bug. ***
The possible columns available in the Bookmark area are:

Name, Location, Keyword, Description, Added, Last Modified, Last Visted

Can another one be added called "Contained In" or something which is filled with
the path to the present bookmark?

I haven't looked at the code, but that seems like a small fix...Anyone?

*** Bug 157275 has been marked as a duplicate of this bug. ***
All in all I'd like to see this feature implemented.  When I want to find out
what folder a specific bookmark is in, I cannot do it, and this gets very
annoying at times.  One more vote for this bug.
I think this bug affects more than just Windows 2000, it effects the entire
Win32 platform to my knowledge.  Any Unix users who can confirm that this is a
"bug" on their platform?  This bug could probably be marked "all OSes".

I think the easiest and most efficient way of fixing this bug would be to
implement  something like the solution described in comment 12.
Yes, I can confirm this behaviour for the Solaris build:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1a) Gecko/20020614
*** Bug 161781 has been marked as a duplicate of this bug. ***
Summary: [RFE]bookmark search results doesn't show where bookmark is → bookmark search results doesn't show where bookmark is
This still hasn't been fixed in Build No. 2002102908. It wastes a great deal of
time when editing bookmarks. (Mac G3, OS 9.2.2; Modern theme.)
This bug is very annoying, and makes "searching" bookmarks very frustrating and
sometimes useless.  
This has got to be the single most embarrassing defect in NS7. A bookmark search
only tells the user if a bookmark exists. It should answer more questions. In
particular, it should tell the user which bookmarks are adjacent to the search
result, since those bookmarks may be logically related.

Clearly, this feature was intentionally broken by an inexperienced programmer.

PS: If no result is found, NS produces an empty window. Very silly, and very
sloppy. The programmer should be severely dressed down in front of family and
coworkers.
Actually, it was done by an experienced programmer, with good intentions.
Should we dup this against bug 95748 or bug 118393, both of which are scheduled
to be fixed for 1.3?
Keywords: mozilla1.0
In comment #25, from Peter Trudelle, he said:
"Actually, it was done by an experienced programmer, with good intentions."

"Intentions" suggests intent, meaning this was done with some sort of reason in
mind. What were the reasons?
Further to Comment #25 below, I have just installed Mozilla Build 2002122608
(i.e. v. 1.3b). The new 'Find' pane at the top of the 'Manage Bookmarks' window
is excellent, but I had hoped that #25 would be fulfilled in 1.3b. It hasn't!
See Comment No.12. There is an easy workaround: make a copy of bookmarks.html
and have it in a convenient place. If you want to locate a bookmark, open
bookmarks.html by double-clicking or by dragging it to any browser or its alias.
It opens with indentations and large-font headings, etc., and 'Find' will locate
the bookmark you are looking for.

But this still should not be necessary; it should be possible to do it in
'Manage bookmarks'.
Bookmark search should also return matching folders.
Shall I open a new bug for this or is this comment ok?
A note on Comment #28 From Michael Graubart:
Even simpler is opening the bookmarks file in the browser, and then bookmarking
the bookmarks file.

My preference for action: leave the current behavior as a feature, but call it
what it is: a Filter.

Then restore the previous Search functionality.
D.E.Jones: Thank you very much for your idea about bookmarking the bookmarks
file.  It is the ideal solution at the present state of Mozilla's bookmarks
system. But I still think that if (as, for example, in Netscape 4) 'Find' shows
the location within the system of folders and subfolders, one can then very
easily move it by dragging without moving to and fro between the opened
bookmarks file and 'Manage bppkmarks'.
> Bookmark search should also return matching folders.
> Shall I open a new bug for this or is this comment ok?

I've received some comments on this and I understood that I should
explain this explicity.

Here it goes:

When I search for "imran" in bookmarks, I also would like to get "bookmark
folders" whose name contains "imran".

That is the search results should include
1- bookmarks named *imran* AND
2- folders named *imran*.

Just like windows explorer's search on file system which returns both matching 
files AND directories.

Is this ok now?
Should open a new bug for this?
Or Shall this bug cover this issue?
Best Regards....
> But I still think that if (as, for example, in Netscape 4) 'Find' shows
> the location within the system of folders and subfolders, one can then very
> easily move it by dragging without moving to and fro between the opened
> bookmarks file and 'Manage bppkmarks'.

I agree that this would be convenient.
But how will you present multiple matches in such a configuration?
Re Imran's last comment and question: If several bookmarks and/or folders whose
name includes 'Imran' are brought up by 'Find' (as they are anyway at present),
it would precisely be the indication of what they are and where they are to be
found that would allow one to identify the one that one wants to open, to modify
or to move to another location. I find Netscape 4.x's system infinitely more
user-frioendly: 'Find' does not produce a separate little window with the
searched-for item in it, but just highlights the item in its place in the whole
'Edit bookmarks' page, so that one can then see what its neighbours and
enclosing folder are and one can do whatever one wants with it.

And talking about modifying it, such a system would also deal with the very
dangerous problem (see bug no.187071) that at present in Mozilla, if 'Find' is
used to bring up a bookmark and it is then modified in some way via the found
window and 'Properties' or 'Command + I', as soon as 'OK' is clicked, the 'Find'
system reverses the last change made anywhere in the bookmarks file via the same
procedure.
Reading the comment and attachment from 'petercd' makes me wonder even more if
there isn't a connection with bug 187071, which concerns the reversion to an
earlier state of the bookmarks file after changes or deletions are made to
bookmarks found by means of 'Find' or the new find-slot at the top of 'Manage
bookmarks'.
According to a poster in n.n7.windows, the identification of the bookmark folder
used to work in NS 4.75. "4.75 (...) would bring me up to which folder it was in."

Can we add 4xp to the list of keywords please?
 
Keywords: 4xp
I have made a discovery related to Comments Nos. 28, 30, 31 and especially 34.

Bug Report 187071 contained a great deal of confusion, due to the apparently
sporadic nature of the reversion of changed bookmark details to earlier
vewrsions. This report has now been superseded by Bug Report 190145. But what I
have now discovered is that it is the opening of bookmarks.html in Mozilla's
Navigator and its bookmarking in the same file (I am not sure whether it is the
opening of the file or the subsequent bookmarking that does the damage) that
seems to create a hidden backup copy of the bookmarks file, which then causes
changes in the file made by using 'Search' or 'Find' to revert as soon as
another change is similarly made and Mozilla is restarted. So the nice ways of
looking at the bookmark file's tree structure are highly dangerous.

What is even worse, it seems that just deleting the bookmark that opens the
bookmark.html file does not remove the problem that has been created. I found
that I had to delete both the main Mozilla folder and the Mozilla folder in
'Documents' that contains the profile(s), re-install Mozilla from scratch and
crteate my profile anew before it was safe to make changes in 'Manage Bookmarks'
again.
*** Bug 196162 has been marked as a duplicate of this bug. ***
*** Bug 201951 has been marked as a duplicate of this bug. ***
I agree: A bookmark "find" function is needed to locate bookmark(s) *within* the
context of the bookmark tree structure.  

Decent bookmark management was one of the best features of NS 4.7 and similar
functionality needs to be added to Mozilla. 

>------ Additional Comment #41 From treefrog74@lycos.com  2003-07-03 20:10 ------

>I agree: A bookmark "find" function is needed to locate bookmark(s) *within* the
>context of the bookmark tree structure.  

>Decent bookmark management was one of the best features of NS 4.7 and similar
>functionality needs to be added to Mozilla. 

You said it, Mozilla has no practical bookmark management. NS 4.7 worked great
in that regard.  I vote Mozilla should be done like Netscape 4.7 in the area of
bookmark searching, the goofy searching method now with opening results in a new
window is nearly worthless. It isn't useable at all.  

This bug has been languishing for 3 years.  Is anyone working on this
functionality?  

*** Bug 188105 has been marked as a duplicate of this bug. ***
Not sure why it's so difficult to implement. At the very least, if the "folder"
column is added to the list of available columns in the "Search results -
Bookmark" window it'll be all that most users need. Can it be done in 1.6? Thanks
*** Bug 232171 has been marked as a duplicate of this bug. ***
I would also like to see this implemented.

As a workaround I'm currently importing my bookmark.html file into IE.
Then I use the Search "For Files and Folders" facility to search my Favorites
folder:
 C:\Documents and Settings\Administrator\Favorites\

This clearly shows any bookmarks/folders that contain my search results, with
the folder it's in shown next to it.

It would be great if Mozilla could provide something similar.
*** Bug 238320 has been marked as a duplicate of this bug. ***
*** Bug 243773 has been marked as a duplicate of this bug. ***
I notice more peeps are sending in dups on this.

The bookmarks as black hole is getting to be more and more serious for more
people.  

The longer you use Mozilla and build up your bookmarks until thre are duplicates
all over that cannot be found.  Which results in the bookmarks being stored in
"buckets".  Unmanageable.

The way bookmarks are handled and managed in Mozilla is a fraction of the
convenience and utility of the handling in the Netscape 4.7 bookmark window, for
example, or anything in any explorer window on any MS windows computer for that
matter. The window focus is an issue as well. If any of the developers would
like that explained I would be delighted, just ask! 

Is anyone going to work on this RFE? It now has 12 "marked as duplicates". 
There is some interest in this one! 

This bug is languishing for years.  3 1/2 years.  
Product: Browser → Seamonkey
(In reply to comment #49)

I agree with Steve 100% for this has been a chief annoyance for several years. 
How can anyone expect the average person to use Mozilla when it contains such
glaring holes -- and such info passes on from one to another.   

My work around has been to add a button to the personal toolbar "BM Search,"
which remains alive with changes, but how is the average user to ever think of
this?  I cannot at all understand why this deficiency has not been corrected
over the years.  Could someone please exlain the difficulty to me.

Miles
(In reply to comment #50)
In response to Ryan's request, here is how to set it up in your Personal
Toolbar.    If you haven't used the PT, see Mozilla Help. (As much as I would
enjoy claiming credit for for this workaround, I cannot for it is based on info
from Ed Mullin in the netscape general newsgroup on the 3rd of February.)
1)   Open Windows Explorer, go into your profile folder, and double click on
"bookmarks.html" which will open it as a webpage.
2)   Drag the location icon to the Personal Toolbar.  Then right
click/properties/ and change the name of the button.
3)   Search as you would any web page, edit/find in this page.

Miles

Miles
(In reply to comment #51)
There may be a problem here if the procedure is similar to the one in comment
30. The response in comment 38 describes possible damage to the bookmarks file.
With reference to Comments 50, 51 and the latest one from Dej81r6@netscape.net
(52?), as the Mozilla user who raised the danger signals mentioned in Comments
30, 34 and 38, I have to report that I have had none of these problems with
recent releases of Mozilla in Mac OS 10.3.7 and 10.3.8. I have tried both the
(related) suggestions: bookmarking the bookmarks file, and now (as a result of
Comments 50 and 51) installing a toolbar button to open the bookmarks file, and
no damage (and no reversion to versions prior to alterations) seem to be done to
the bookmarks file if either of these is used to open the file and search in it.

I must repeat, though, that a reversion to the system of locating bookmarks in
their context found in Netscape 4 would still seem a much better solution,
avoiding having to alternate between two different pages.
Guess I hadn't closely read all of the details in this thread, else I wouldn't
have done it.  However, it is working fine after a couple of weeks.  And I do
have a Bookmarks.bak file so all would not be lost.  However, do not want to go
through the exercise of rebuilding a new profile!

Curious as to whether this has yet been tested as to if the failure was on a
Mac?   Was it also found in Windows -- 2000, XP SP1, SP2?   And which versions
of Mozilla?

Miles
Blocks: majorbugs
Have been away for a month and upon return discovered that placing the bookmark
button in the Personal Toolbar creates a new bookmark file, "bookmarks-1.html,"
which becomes the file in use when bookmarks are opened in the normal fashion of
clicking on the "bookmarks" button or Control/B and when BM's are added or changed.

The old "bookmarks.html" continues to be used by the Personal Tool bar button,
however it is inaccurate, as additions and changes are not included.   Therefore
this is not a  solution.

Has bookmark search been corrected in Firefox?  If so, that may be sufficient
reason to change over to the two programs in lieu of Mozilla's combo.   Or
perhaps Netscape continues to operate as it should????

Miles
Interesting that this is the third time this msg has been sent and although I
received an email reflecting the contents, it is not listed on the bug page. 
Perhaps the site is down and hopefully three dupes will not appear on the page!

Have been away for a month and upon return discovered that placing the bookmark
button in the Personal Toolbar creates a new bookmark file, "bookmarks-1.html,"
which becomes the file in use when bookmarks are opened in the normal fashion of
clicking on the "bookmarks" button or Control/B and when BM's are added or changed.

The old "bookmarks.html" continues to be used by the Personal Tool bar button,
however it is inaccurate, as additions and changes are not included.   Therefore
this is not a  solution.

Has bookmark search been corrected in Firefox?  If so, that may be sufficient
reason to change over to the two programs in lieu of Mozilla's combo.   Or
perhaps Netscape continues to operate as it should????

Miles
Re Comment #56: Miles is absolutely right. Thank you, Miles, for drawing my
attention to the possible confusion that the two different bookmarks files could
cause. And I do feel strongly that a solution like that of the old Netscape 4.x
would be much better. But there is a provisional solution in Mozilla as at
present constituted: instead of a Personal Toolbar button (which should be
removed, as Miles implies), go to your own profile, find 'bookmarks.html',
double-click on it to open it and click on 'Bookmark this Page' in Bookmarks on
the main toolbar. This results in a bookmark for the bookmarks file in the list
of bookmarks. It works exactly like the button did (and is just as easy to
open), but — unlike the button — does not create a new 'bookmarks-1.html' file.
Appreciate your quick response, Michael.  I changed the name of the
bookmarks-1.html file to bookmarks.html (first making a backup) and deleted the
Personal Toolbar button and the old bookmarks.html file, but when Moz is
reopened and bookmarks is again opened a new "-1" file is created.  

Do you happen to know where this relationship is stored so that this can be
cleaned up prior using your method?

Miles
Miles, re your Comment #58: This is very curious. Last night (after reading your
previous comment) I removed the Personal Toolbar button, went to Library ->
Mozilla -> Profile, opened the folder with a lot of gibberish and .sit as its
name, found the two bookmarks files, opened each in turn to see which had my
most recent changes, deleted the other, made sure the remaining one was called
'bookmarks.html', opened it again, bookmarked it as described in my previous
Comment, opened it from within the bookmarks drop-down menu, went back to check
that no new file had been created and eventually shut down Mozilla and my
computer. This morning I restarted the computer and Mozilla, checked and found
(unlike you, evidently) that no new file had been created, opened the bookmarks
file from within the drop-down list, went back and checked again - and still no
new bookmarks file had been created. 

I use an eMac G4 with OS X 10.3.8. Perhaps you are using a different set-up?

I am afraid I do not understand enough about the inner workings of the computer
or of Mozilla to know more about how and where all this happens. I am not a
programmer or anything like that, only a user of Mozilla. 
(In reply to comment #59)
Just tried it again and apparently Windows XP Home SP1 differs from Mac. 
Changed the name of bookmarks-1.html to bookmarks.html with Moz closed. 
Reopened Moz and again found a newly created blank bookmarks file,
bookmarks-1.html.  Deleted it, changed bookmarks.html to bookmarks-1.html and
it's OK.

Also checked folder program files/mozilla.org/mozilla/defaults/profile where
there is a 2kb bookmarks.html containing Personal Toolbar, Mozilla Project, and
Search the web.  The same file exists under the sub-folder US.  Also found no
mention of bookmarks in about:config.

Hopefully someone listening in will have the solution??
Glad it's OK now — but really and truly there shouldn't be any need for this
palaver, and renaming the bookmarks file and so on. This issue (of Mozilla not
showing where a bookmark lives) has been dragging on ever since I've started
taking an interest in Mozilla — several years. If Netscape 4 had a simple
solution, and IE has more or less the same solution now, surely it can't be
beyond the wit of man — Mozilla-man — to revert to something like it in Mozilla.
Shouldn't this be a "Core" bug instead of "Mozilla Application Suite"?

I am seeing the exact same thing in Firefox.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050404
Firefox/1.0+
Shouldn't this be a "Core" bug instead of "Mozilla Application Suite"?

I am seeing the exact same thing in Firefox.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050404
Firefox/1.0+
worcester12345@yahoo.com: no, because the code is forked.
Assignee: bugs → p_ch
QA Contact: claudius → bookmarks
No longer blocks: majorbugs
*** Bug 325923 has been marked as a duplicate of this bug. ***
Reassigning as per Bug #32644
Assignee: p_ch → nobody
I just now reviewed the comments for this bug, for bug #95748, and for bug #118393.  These all appear to be duplicates of each other.  Two should be closed.  

Regarding the various work-arounds cited in this bug report, I specify my bookmarks file as my home page since I discovered that was what I most often wanted to see.  Searching for a bookmark is thus very easy and I avoid the proliferation of bookmarks-n.html files.  

However, the problem with the current design is most apparent after I find a bookmark.  The issue is:  What can I do with the found entry?  From my bookmarks file as my home page, I can only select the link.  From Search Results window (after Ctrl-F on the Bookmarks Manager window), I can also manipulate an entry.  

BUT HOW DO I DELETE A FOUND BOOKMARK?  I can't!  I could if Ctrl-F did a search within the Bookmarks Manager window instead of opening a new window (as requested in bug #95748).  Since deleting a bookmark is a necessary capability, the current design is useless.  (I think it is strange that none of the comments in any of these three bug reports even mentions deleting a found bookmark.)   
> (I think it is strange that none of the comments in any of these 
> three bug reports even mentions deleting a found bookmark.)  

Actually, it's probably not so strange after all.  

Deleting a bookmark does not require knowing the location of the 
bookmark.  It only requires identifying the bookmark to delete.

Solutions that would take care of the case of deleting a bookmark
would not (necessarily) take care of the general case:  finding the 
location of a bookmark to do something with its location (move it,
find it siblings, parent, etc.).


 








You don't actually
need to find the location of a bookmark to delete it.  Once you identity
it, you cou


  Being able to find
the location of a bookmark to see


To delete a bookmark, you
(theoretically


  It's more important to be 
able to find the current location of a bookmark who



Actually, it's probably not strange.  To delete a bookmark, you only need
to identify the bookmark and then delete it.  (Once 
> (I think it is strange that none of the comments in any of these 
> three bug reports even mentions deleting a found bookmark.)  

Actually, it's probably not so strange after all.  

Deleting a bookmark does not require knowing the location of the 
bookmark.  It only requires identifying the bookmark to delete.

Solutions that would take care of the case of deleting a bookmark
would not (necessarily) take care of the general case:  finding the 
location of a bookmark to do something with its location (move it,
find it siblings, parent, etc.).
 
(In reply to comment #33)
> > But I still think that if (as, for example, in Netscape 4) 'Find' shows
> > the location within the system of folders and subfolders, one can then very
> > easily move it by dragging without moving to and fro between the opened
> > bookmarks file and 'Manage bppkmarks'.
> 
> I agree that this would be convenient.
> But how will you present multiple matches in such a configuration?

One at a time, just like Netscape 4 did it.  Just like the find-text
command in most text editors, word processors and browsers.


>Deleting a bookmark does not require knowing the location of the
>bookmark.  It only requires identifying the bookmark to delete.

I TOTALLY disagree, sometimes I end up with multiple copies of the same bookmark and I particularly want to know where the bookmarks are located (CONTEXT) so I can decide the right one to delete.

Another thing to mention, while I'm at it, is that I wish a bookmark folder would turn up in the search results too.  The containing folder name is context that I personally associated with the bookmark -- very important for finding, very related to the bookmark itself.  Sometimes I'm actually more interested in finding the folder and it's location, so I can see what other bookmarks are there.
    No, suppose a town has 10 people named Daniel B.  I only want my friend
    from Smartnet Town.  So which ones to delete can be context dependent.

    what we really need is a way of SHOWING the locations of bookmarks
    that match the search criterion WITHOUT CHANGING THE BOOKMARKS DISPLAY.

    This can be easily done by highlighting the bookmarks with a special color
    (different from the normal highlight).  When I highlight, I see green.
    Using shift I can highlight several bookmarks in green.  Let's say the
    identified sites are highlit in blue.  Sites highlit by me AND by the
    search could be in purple.  (Or chose another color scheme.)

    If a bookmark is inside a folder, COLOR THE FOLDER DIFFERENTLY.
    DO NOT OPEN THE FOLDER.  As long as there is text in the search
    window, allow the user to manipulate the folders themselves, including
    deletion.
Oops.  Sorry about that posting with unpurged draft text.
(In reply to comment #72)
...
>     what we really need is a way of SHOWING the locations of bookmarks
>     that match the search criterion WITHOUT CHANGING THE BOOKMARKS DISPLAY.
...

That makes me think of how WebLogic Workshop's text editor works (and 
how I think Eclipse probably works):

- When you do a find-text-in-current-file command, along with moving 
  the text cursor to the next match, the editor also puts marks in 
  the (vertical) scrollbar background to indicate where matches occur. 
  Clicking on mark takes you to the line containing that match.
  (I think it might also highlight all matches currently visible in
  the viewport.  In any case, Emacs highlights other visible matches
  like that.)

- When you do a find-text-in-multiple-files command, the editor creates 
  a list of matches (showing the name of the file and the line 
  containing the match).

Note that there are three (or four) kinds of finding going on: 

1. Taking you to the location of a match (one at a time) so you can
   operate on it (and/or move to and operate on nearby things).

   That corresponds to how Netscape 4's bookmark-find command works.

   (I use present tense because I still use Netscape 4.7x specifically
   because Mozilla/etc.'s bookmark management is unusable for
   maintaining large bookmark files.) 

2. Telling you where not-currently-visible matches are, using some 
   analog (the scrollbar background) for the locations that you can 
   take you to an actual location.

   That corresponds (partly) to your idea to highlight folders that
   contain matches.  That highlighting tells you where (in which
   folders) matching bookmarks are, even if they aren't currently 
   visible (if the folder view is collapsed).  Although a 
   highlighted folder icon doesn't take you to an individual matching
   bookmark, it does take you to the contents of the folder (by
   expanding the folder view and making the contained bookmarks 
   visible).

3. Showing you a new, separate list of things that match.  (More 
   precisely, its a list of copies or representations of the things
   that match.)  

   That's (somewhat) how Mozilla's bookmark searching currently works.

   (Actually, in the editor, the main thing you do with the items in
   the list is read them or click on them to go to the location of
   the actual matching text.  That doesn't correspond exactly to
   opening a bookmark from Mozilla's list, but does suggest that from
   Mozilla's list, you should be able to get to the location of the
   bookmark (in some folder).)

4. (Should be numbered 1.5:)  Directly showing you the locations of other
   matches that are currently visible in your viewport.  

   This corresponds to your idea to highlight bookmarks that match.


Since the text editors' users/creators found it useful to provide all 
four kinds of finding for text, maybe all four are useful for bookmarks. 

Note that it doesn't take four different find commands, probably 
only two.

I have just read through a mass of comments about this problem (I'm surprised and pleased that it has resurfaced!), and still think that for most purposes just reverting to the Netscape 4 model would be the simplest, most intuitive and straighforward solution.

But as what is actually a separate issue, I quote from Comment #67: 'I avoid the
proliferation of bookmarks-n.html files.' Only, surely, if you do indeed never delete bookmarks? You can't delete from the Bookmarks file itself, but if you then  open Bookmarks Manager and delete a bookmark, a new 'bookmarks-n.html' will be created either straight away or after closing and reopening SeaMonkey or whatever, depending on which branch and build you are using. See Bug 334941.
(In reply to comment #71)
> >Deleting a bookmark does not require knowing the location of the
> >bookmark.  It only requires identifying the bookmark to delete.
> 
> I TOTALLY disagree, sometimes I end up with multiple copies of the same
> bookmark and I particularly want to know where the bookmarks are located
> (CONTEXT) so I can decide the right one to delete.

Yes. A duplicate detector would come in handy here too.

> Another thing to mention, while I'm at it, is that I wish a bookmark folder
> would turn up in the search results too.  The containing folder name is context
> that I personally associated with the bookmark -- very important for finding,
> very related to the bookmark itself.  Sometimes I'm actually more interested in
> finding the folder and it's location, so I can see what other bookmarks are
> there.

Same here. I would think an indent with the folder name above would do the trick.
*** Bug 118393 has been marked as a duplicate of this bug. ***
Reference comment #69:  

My preferences are set to make my bookmarks file my home page.  According to a survey a year or so ago in Mozillazine, this is common.  My bookmarks file contains approximately 1,000 entries, organized by topics.  

Last night, I selected a bookmark from the displayed page; but it was 404.  Thus, I decided to delete it.  I launched Bookmark Manager, searched on a word in the name of the bookmark, and tried to delete it.  In the Search Results window, [Edit > Delete] is disabled (grayed out).  The Delete key on my keyboard had no effect.  A right-click gave me a context pull-down menu where the Delete item was also disabled.  

No, you cannot search for a bookmark and then delete it.  
Re #69: I do not have my bookmarks file as my homepage. I do have my bookmarks file as an actual bookmark. If I open this, I can search for other bookmarks and find out where they are located. I can then navigate to that location in Bookmarks Manager and delete the bookmark. My method of identifying the location of that bookmark (i.e. whether I had previously searched in the bookmarks file itself or had used a combination of guesswork and luck to discover its location) has absolutely nothing to do with what I do with it afterwards. What is certainly true is that if I find a bookmark by using the search facility in Bookmarks Manager, I cannot delete it from there. But that has nothing to do with having the bookmarks file as a bookmark (whether named as home page or not). What is equally true is that all this is a time-wasting procedure which would be quite unnecessary if the bookmarks system reverted to the old Netscape 4 system.
given this is 4xp it's a bug, not enhancement.
Severity: enhancement → normal
Summary: bookmark search results doesn't show where bookmark is → add folder column so bookmark search results shows where bookmark is in folder heirarchy
Blocks: 164711
Blocks: 323813
Summary: add folder column so bookmark search results shows where bookmark is in folder heirarchy → add folder column so bookmark search results shows where bookmark is in folder hierarchy
Gentlemen & Ladies,

I think everyone is off track (for over 7 years) and no decision has been made to add the original requested enhancement:

"Add folder column so bookmark search results to show where bookmark is in folder hierarchy."

Heck, it could be as simple as showing its location in the status bar.

Please help and implement this simple request.

Thanks, andy
> "Add folder column so bookmark search results to show where bookmark is 
> in folder hierarchy."

How would the user get to that folder? 

If you did something like making that column's entries be links that 
take the user to the folder in the bookmarks management window, that 
_might_ help.  

(That would make it almost like Windows' file search function's "Open
containing folder" action.  I'm not sure I'd like that (it might be 
better sometimes, but might be worse sometimes), but it would be much
better than the current situation.)


> Heck, it could be as simple as showing its location in the status bar.

No, it couldn't be that simple:
- If you just showed the folder's simple name then obviously you wouldn't 
  be showing enough.
- If you showed the folder's whole pathname, you're likely to overflow
  the status bar and obviously not really show the whole pathname.
- Even if the whole pathname fits in the status bar, just _showing_ the 
  name is next to useless--the user would have to manually navigate to 
  the folder, which would be a royal pain for any but the simplest
  folder hierarchies.  

  (That would also violate the principle that if data is on the screen/
  page/etc, the user should never have to re-enter it.  If the user can't
  copy the folder pathname from the status bar and paste it into something
  (like a file selection dialog box that takes a pathname) and get to the 
  folder, you've violated that principle.)

Why, O why, did Mozilla/SeaMonkey ever desert the old Netscape 4 system? Which was very like the current, excellent Safari one: I type Command-F, type in a name, click 'Next' and I see the relevant part of my bookmarks list, with the folder in which what I'm looking for is contained already open, and all I have to do is double-click the bookmark.
Re my comment above (#83): perhaps I should have added that, like many SeaMonkey users, I have bookmarked my bookmarks file (in my bookmarks file!). At one time that seemed to create certain problems, but now (at any rate in SM 1.1) it doesn't seem to. And it works just like the Safari system I described above; I don't even have to double-click a found URL, because single-clicking takes me to the desired site.  

It can't be very difficult, can it, just to make it look a bit more elegant when one uses it, and make it the default bookmnarks system?
Re my comment above (#83): perhaps I should have added that, like many SeaMonkey users, I have bookmarked my bookmarks file (in my bookmarks file!). At one time that seemed to create certain problems, but now (at any rate in SM 1.1) it doesn't seem to. And it works just like the Safari system I described above; I don't even have to double-click a found URL, because single-clicking takes me to the desired site.  

It can't be very difficult, can it, just to make it look a bit more elegant when one uses it, and make it the default bookmarks system?
In FF I have been using extension Advanced Bookmark Search which has resolved most of the difficulty in that a search produces a location column.  If this extension also operates with SM, it just have resolved most of the problems we have faced for  a few years!

(FYI, additionally am using Flat Bookmark Editing which I believe is the extension that takes a bit of real estate with a box at the bottom of the screen where name, location, etc. is seen and can be edited.  Therefore after locating bookmark(s) in a search you can quite easily see differences and change info.)
Miles (#86) - thanks for the interesting tip!  Can you please tell
us the url of the plugins and how one installs them?  Whether they
install in SeaMonkey properly would also be useful to know ...
Didn't find where the authors said whether or not they operate with SM; guess you'll have to simply try them or ask the authors if it presently does or if it could easily be converted.

Advanced Bookmark Search is at:
https://addons.mozilla.org/firefox/3543/
and
http://hlgeniusos.blogspot.com/

Flat Bookmark Editing is at:
http://bluweb.com/us/chouser/proj/mozhack/
and
https://addons.mozilla.org/firefox/117/
Re #88: I have just tried to install Adv. Bookmark Search in SeaMonkey 1.1.1, and got 'Install script not found'. I haven't tried Flat BM Editing; nor have I tried installing either of them in the current Trunk version of SM.
Duplicate of this bug: 352404
This feature is still not available in Firefox 3.0 B5 and I have found no extension working for it.
The 'Advanced Bookmark Search' extension contains the ability to see the path of a bookmark after searching. See https://addons.mozilla.org/en-US/firefox/addon/3543
GEEZ!!  This is VERY basic functionality, it SHOULD NOT require a damn 'extension'!!!!!!
One more vote from me. I think all of the suggestions should be implemented:

1. 'Open Containing Folder'
2. Current sub-folder is selected on the left hand side
3. New column: 'Contained In'

waiting for this feature also for a long time now. Hoped to see it in 3.0 - but nope ...
Why do basic functions like this take 8 years to not-yet implement?
Is anyone actually working on the browser anymore?
For 3.0 a nice couple of extensions that shows the location in a BM search is ShowParentFolder:

https://addons.mozilla.org/en-US/firefox/addon/7372

coupled with GoParentFolder:

https://addons.mozilla.org/en-US/firefox/addon/7377

I haven't checked if they work in SM or in 2.0 -- perhaps only for sqlite?

(In reply to comment #96)
> For 3.0 a nice couple of extensions[]

Bottom line:  THIS SHOULD **NOT** REQUIRE AN EXTENSION!!!!  IT SIMPLY SHOULD WORK!!!  

At least they've stepped forward somewhat in the v. 3 functionality, but crikey, come on!!!
Agree that this should be core functionality. I have a complex set of bookmarks and folders, and this problem devalues Firefox for me.
(In reply to comment #97)
> Bottom line:THIS SHOULD **NOT** REQUIRE AN EXTENSION!! IT SIMPLY SHOULD WORK!! 

Agree 100% that it should be native, not an extension.  I merely pointed that out so those who aren't aware of the extension can eliminate some Firefox aggravation until it is fixed hopefully in 3.1. 
Duplicate of this bug: 196509
In bug 469416 (Add "Folder" to the properties pane of bookmarks when viewing search results), I attached a sample UI (attachment 392021 [details]) which includes the folder column proposed by this bug and FF bug 469421. It also includes
- "View containing folder" button (bug 469441)

With respect to this bug, I assume Folder column should show full path within the All Bookmarks context. We'll need to agree on a separator between nested folders, I am proposing colon (:), since it's not a file system path.
Comments welcome.
I don't know what you mean by a colon not being a "file system path". I don't see why this would be relevant, but colons can, of course, be part of a file system path:

$ mkdir 'abc:345'
$ ls -al abc\:345/
total 8
drwxrwx---  2 toni toni 1024 2009-08-01 14:36 ./
drwxrwxrwt 11 root root 7168 2009-08-01 14:36 ../

The backslash in the command above is a result of Bash's auto-quoting when using tab-expand.

More importantly, folders in the sense of folders in bookmarks afaik don't correspond with file system paths in any way and also are probably more prone to contain colons, like eg. in "software: my todo list", which would then be what I expect to see. Instead of using an ascii character to separate the components in the listing, it'd probably be better to have something that is not easily typed or otherwise used, eg. an image, which would be displayed to the user. For computing purposes, the bookmark path could be a structured XML-or-something, anyway, so it doesn't matter in that area, and since the image is only relevant in the UI and Mozilla apps all require a GUI anyway, I currently don't see potential breakage in that area.

Just guessing, though - I don't have statistical data to back these claims up.
(In reply to comment #102)
> I don't know what you mean by a colon not being a "file system path". I don't
> see why this would be relevant, but colons can, of course, be part of a file
> system path:

What I meant was: I am proposing colon (:), since a bookmark folder path is not a file system path, so probably we should not use (back)slashes (/ or \). :)

I didn't consider that colons can be used for bookmark folder names as well. The graphical implementation you propose would be nice, but unless you code this yourself maybe we should go for easier (read: faster) implementations first. 9 yrs after this bug has been filed, I guess most people will be more than happy with a text-only solution to start with. Any one-character alternatives for the colon? What about using "}", e.g.
All bookmarks } Bookmarks Menu } MyFolder?
Why be complicated?  On a find, don't open a new window for the results; just scroll the main Bookmarks Manager window to the next found instance.  That way, all Bookmarks Manager functionality will be available at the found bookmark.
Re Comment #104: Is this a proganmming suggestion for the people working on the development of the program, or is it something one can do with the Bookmarks Manager as it exists at present? If the latter, I can't see how to do it, I am afraid.
My comment #104 was a programming suggestion.  It seems to me that an implementation of this suggestion would likely make the Bookmarks Manager somewhat smaller by eliminating code relative to opening a separate window just for searching.  It would also make searching easier for users.  

Note:  This suggestion merely reflects the way Netscape 4 used to work.
Thanks for the explanation. I am only a user of the end-product, but I used to find the way searches worked in Netscape 4 simple, clear and effective.
Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20111221 SeaMonkey/2.6.1

This is still a problem with the current (new) Bookmarks Manager.  Having structured my bookmarks into folders and subfolders, I cannot determine where in that structure a found bookmark is located.  

Is this now a Toolkit/Places bug?
Presumably this bug is for Firefox as well as SeaMonkey.  I've been complaining for years.  A current example of the difficulty it causes is:
Frequently I find need to save several open tabs dealing with a certain subject.  So they are saved to the bookmarks/temporary folder.  Without a spacer by name these temporary bookmarks cannot be distinguished from the other BM's in that folder.
(In reply to Miles from comment #109)
> Presumably this bug is for Firefox as well as SeaMonkey.  

Well, Firefox and SeaMonkey do suffer from the same problem, but this bug only covers SeaMonkey (see Product attribute above).
For FireFox, there's bug 469421.

> Without a
> spacer by name these temporary bookmarks cannot be distinguished from the
> other BM's in that folder.

I'm not very sure what exactly "spacer by name" refers to, and I'm not sure if it should be part of the proposed solution of this bug.
Summary: add folder column so bookmark search results shows where bookmark is in folder hierarchy → [SM] add folder column so bookmark search results shows where bookmark is in folder hierarchy
There are at least 4 outstanding bug or enhancement requests on this topic covering 150+ votes to solve a simple problem which should have been solved a long LONG time ago.

The very simple problem is that when you search for and find one or more bookmarks in ANY part of firefox (v10.0.2 Windows in my case) there is absolutely ZERO way of telling **WHERE** that bookmark came from in your extensive, thousands upon thousands of bookmarks.

You "find" it but you can't really figure out where it CAME from.
There is no way to determine what folder inside of a folder inside of whatever folder that bookmark is located.  You can't go to that folder.

The information is useful and needed because sometimes you are retrieving a bookmark and know it is from a larger batch of bookmarks dealing with the same topic or issue.  You know enough to find one of the bookmarks (via search) but you are dead-in-the-water cause there is no way to find the rest of them or go to the folder holding it.

(Yes, I suppose you could export your entire bookmark list in HTML format, load it up and then search that way, but that isn't really a solution is it?)

There is simple solution/request.

For any bookmark which is retrieved from:
1) the 'anything bar' (or whatever we call the URL searching process);
2) the bookmarks sidebar search, or
3) the "Library Organizer" bookmark search...

All bookmarks from these retrieval/search mechanisms should be able to be right-clicked->properties and show the Folder location (in the bookmarks tree) of the bookmark, *OR* (in the case of the Libaray which has columns) the location should appear, if selected, as one of the column values such as Tags, Last Accessed, etc.

Again...the simple act of finding out where a bookmark came from is impossible using normal means.  These bugs have been here for years and all other browsers I'm aware of do this normally.  What is the problem?

Bookmarks can already be right-clicked and choose properties.  Can't we just add an extra field to show the bookmark location??  Library organize already has columns for all the other bookmark attributes, can't one be added to show location?

(PS: the use of the word "Location" on bookmark attributes to denote "URL" is just extra confusing if/when the actual bookmark TREE location is included.  I don't know what you call the new attribute if "Location" is already used for "URL", but I digress.)

FYI: I found the following bug tickets addressing the same basic issue (I'm sure there are more.  I only waded through about 150 before giving up.)  Could someone consolidate them (and the votes!) as well?

BUG: 469421
BUG: 469416
BUG: 527225
This should make clickable links to those duplicate bugs:

Bug 469421
Bug 469416
Bug 527225
(In reply to k73qq55wftttt2chb424 from comment #111)
> (Yes, I suppose you could export your entire bookmark list in HTML format,
> load it up and then search that way, but that isn't really a solution is it?)
> 
> There is simple solution/request.
> 
> For any bookmark which is retrieved from:
> 1) the 'anything bar' (or whatever we call the URL searching process);
> 2) the bookmarks sidebar search, or
> 3) the "Library Organizer" bookmark search...
> 
> All bookmarks from these retrieval/search mechanisms should be able to be
> right-clicked->properties and show the Folder location (in the bookmarks
> tree) of the bookmark, *OR* (in the case of the Libaray which has columns)
> the location should appear, if selected, as one of the column values such as
> Tags, Last Accessed, etc.
> 
> Again...the simple act of finding out where a bookmark came from is
> impossible using normal means.  These bugs have been here for years and all
> other browsers I'm aware of do this normally.  What is the problem?
> 

Hello,
you should check this addons:

Show Parent Folder 
Go Parent Folder

They do exactly what You want.
I can't imagine using bookmarks without any of them but I agree that it should be standard FX feature and I was very surprised as well that it wasn't.
Probably this bug is not fixed beacause there's a workaround using those addons, but then again - code in those addons is already in place and could probably be used.
> you should check this addons:
> 
> Show Parent Folder 
> Go Parent Folder
> 
> They do exactly what You want.

Nice. Please, show link to this addons for seamonkey.
(In reply to alntnm from comment #113)
> (In reply to k73qq55wftttt2chb424 from comment #111)
> > (Yes, I suppose you could export your entire bookmark list in HTML format,
> > load it up and then search that way, but that isn't really a solution is it?)
> > 
> > There is simple solution/request.
> > 
> > For any bookmark which is retrieved from:
> > 1) the 'anything bar' (or whatever we call the URL searching process);
> > 2) the bookmarks sidebar search, or
> > 3) the "Library Organizer" bookmark search...
> > 
> > All bookmarks from these retrieval/search mechanisms should be able to be
> > right-clicked->properties and show the Folder location (in the bookmarks
> > tree) of the bookmark, *OR* (in the case of the Libaray which has columns)
> > the location should appear, if selected, as one of the column values such as
> > Tags, Last Accessed, etc.

Doesn't work in SM 2.0.15pre: Properties does not show the required information, and there is no column for it in the Library, either.
> > 
> > Again...the simple act of finding out where a bookmark came from is
> > impossible using normal means.  These bugs have been here for years and all
> > other browsers I'm aware of do this normally.  What is the problem?
> > 
> 
> Hello,
> you should check this addons:
> 
> Show Parent Folder 
> Go Parent Folder
> 
> They do exactly what You want.
> I can't imagine using bookmarks without any of them but I agree that it
> should be standard FX feature and I was very surprised as well that it
> wasn't.
> Probably this bug is not fixed beacause there's a workaround using those
> addons, but then again - code in those addons is already in place and could
> probably be used.

(In reply to Igor Velkov from comment #114)
> > you should check this addons:
> > 
> > Show Parent Folder 
> > Go Parent Folder
> > 
> > They do exactly what You want.
> 
> Nice. Please, show link to this addons for seamonkey.

(In reply to Igor Velkov from comment #114)
> > you should check this addons:
> > 
> > Show Parent Folder 
> > Go Parent Folder
> > 
> > They do exactly what You want.
> 
> Nice. Please, show link to this addons for seamonkey.

I'm afraid they do not work in SeaMonkey 2.0.15pre, which is the latest version I can use on my Mac G4 with OS X 10.4.11. Are there versions for SM 2.0.x?

(In reply to alntnm from comment #113)
> (In reply to k73qq55wftttt2chb424 from comment #111)
> > (Yes, I suppose you could export your entire bookmark list in HTML format,
> > load it up and then search that way, but that isn't really a solution is it?)
> > 
> > There is simple solution/request.
> > 
> > For any bookmark which is retrieved from:
> > 1) the 'anything bar' (or whatever we call the URL searching process);
> > 2) the bookmarks sidebar search, or
> > 3) the "Library Organizer" bookmark search...
> > 
> > All bookmarks from these retrieval/search mechanisms should be able to be
> > right-clicked->properties and show the Folder location (in the bookmarks
> > tree) of the bookmark, *OR* (in the case of the Libaray which has columns)
> > the location should appear, if selected, as one of the column values such as
> > Tags, Last Accessed, etc.
> > 
> > Again...the simple act of finding out where a bookmark came from is
> > impossible using normal means.  These bugs have been here for years and all
> > other browsers I'm aware of do this normally.  What is the problem?
> > 
> 
> Hello,
> you should check this addons:
> 
> Show Parent Folder 
> Go Parent Folder
> 
> They do exactly what You want.
> I can't imagine using bookmarks without any of them but I agree that it
> should be standard FX feature and I was very surprised as well that it
> wasn't.
> Probably this bug is not fixed beacause there's a workaround using those
> addons, but then again - code in those addons is already in place and could
> probably be used.
(In reply to Igor Velkov from comment #114)
> > you should check this addons:
> > 
> > Show Parent Folder 
> > Go Parent Folder
> > 
> > They do exactly what You want.
> 
> Nice. Please, show link to this addons for seamonkey.

google:
Show Parent Folder  Go Parent Folder
gives:
https://addons.mozilla.org/en-US/firefox/addon/go-parent-folder/
https://addons.mozilla.org/en-us/firefox/addon/show-parent-folder/
but unfortunately both are "Not available for Firefox 2.7.2"
BUT THAT IS BEING WORKED ON:
https://bugzilla.mozilla.org/show_bug.cgi?id=732831
Re comment #116:  This is why an extension should not be considered a solution.  It is merely a temporary workaround.
(In reply to David E. Ross from comment #117)
> Re comment #116:  This is why an extension should not be considered a
> solution.  It is merely a temporary workaround.

Agreed.  Even if it is temporary, the ability to identify a bookmark in the global context should have been part of the design from the beginning and it's a major flaw in the current design. I have to write out my booklist as an html and search that
to identify locations, which is awkward and slow.  Why is making a button for displaying the bookmarks as html difficult?  It's been 12 years since this design flaw bug was reported.
Still valid request
Whiteboard: [2012 Fall Equinox]
This is "amusing". We're coming up on this request's 12th birthday...

I don't have any experience with the XUL stuff, but I was under the impression it was designed to make these kinds of details easy to do...

Implementing this as an extension is fine by me, as long as it is always installed. However, I don't even use Netscape/Mozilla/Firefox any more, so my opinion might be moot.
I'm unfamiliar with the feature request process. Does the project team have a way of finding/recognizing requests for consideration? Or must the requester promote the bug so that it is recognized?

The OP request is a feature that I miss having every time I search my bookmarks. PLEASE consider adding this feature in the next Firefox release.

...added my vote.
This makes me nervous. So much time to fix, and what…?! Surely, it is VERY annoying to be able to find a bookmark and NOT be able to see where it is located in one's bookmarks folder!!!
High time to fix!
WONTFIX because we have add-on " Go Parent Folder 2.9.1.1-signed " <https://addons.mozilla.org/en-US/seamonkey/addon/go-parent-folder/?src=search> what solves the problem.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
(In reply to Rainer Bielefeld from comment #123)
> WONTFIX because we have add-on " Go Parent Folder 2.9.1.1-signed "
> <https://addons.mozilla.org/en-US/seamonkey/addon/go-parent-folder/
> ?src=search> what solves the problem.

Ok!  I'll try that ...

> Not available for SeaMonkey 2.39?
> 
> This add-on is not compatible with your version of SeaMonkey because
> of the following:
> 
> You need to be using Firefox 10.0 or higher.

I have the latest - 2.39 - and it says there are no updates available.

So this doesn't appear to be a solution!
Indeed "Go Parent Folder" doesn't seem to be for Firefox anymore. Anyway, for having used it a few years ago, it was a kind of workaround, definitely not a solution: you had to right-click on your bookmark and ask it to take you to its parent folder.

The functioning we are all looking for would be similar to what Eclipse has been doing forever in its settings page (I also haven't used it recently but that's how it was 10 years ago): start typing your search and it shows you everything related to it - including, for each result, where it is located.
(In reply to Guillaume from comment #125)
> start typing your search and it shows you
> everything related to it - including, for each result, where it is located.

That's exactly what "Go Parent Folder" add-on offers for the SeaMonkey "Manage Bookmarks" dialog.
My bad, didn't try hard enough - the add-on actually works for Firefox (44.0). But I don't see any difference in the Bookmarks sidebar, nor in "Show all bookmarks" aka Library. Except for this "Go Parent Folder" option on right click which does... take you to the parent folder, as it always did.

Would the feature you are describing work only on SeaMonkey?
Sidebar is a completely different area. Boomkarks sidebar currently does not support columns at all ...
Columns are not needed to isolate a specific (searched for) bookmark and show it in its parent tree at the same time, are they?

This kind of fix would be such a breeze for those who actually use the bookmarks tree to sort a lot of them! But anyway I guess after time we've all got used to not being able to manage a big collection of new and old bookmarks at the same time, and Chrome doesn't do better, so...
While I don't agree that basic deficiencies should be marked wontfix just because someone wrote an addon to workaround them, the addon you're looking for is Show Parent Folder https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder/?src=userprofile, not Go Parent Folder. They are by the same developer.
(In reply to Michael Schmitt from comment #130)
> While I don't agree that basic deficiencies should be marked wontfix just
> because someone wrote an addon to workaround them, the addon you're looking
> for is Show Parent Folder
> https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder/
> ?src=userprofile, not Go Parent Folder. They are by the same developer.

That's the wrong link for SeaMonkey, apparently.  Switch the word 'firefox' to 'seamonkey':
https://addons.mozilla.org/en-US/seamonkey/addon/show-parent-folder/?src=userprofile
There one finds:

Not available for SeaMonkey 2.39
This add-on is not compatible with your version of SeaMonkey because of the following:
    You need to be using Firefox 10.0 or higher.

Of course I do not want to use Firefox (most of the time) since SeaMonkey has a better design.

Has anyone tried this and does it work for SeaMonkey anyway?
(In reply to Tom Schneider from comment #131)
> (In reply to Michael Schmitt from comment #130)
> > While I don't agree that basic deficiencies should be marked wontfix just
> > because someone wrote an addon to workaround them, the addon you're looking
> > for is Show Parent Folder
> > https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder/
> > ?src=userprofile, not Go Parent Folder. They are by the same developer.
> 
> That's the wrong link for SeaMonkey, apparently.  Switch the word 'firefox'
> to 'seamonkey':
> https://addons.mozilla.org/en-US/seamonkey/addon/show-parent-folder/
> ?src=userprofile
> There one finds:
> 
> Not available for SeaMonkey 2.39
> This add-on is not compatible with your version of SeaMonkey because of the
> following:
>     You need to be using Firefox 10.0 or higher.
> 
> Of course I do not want to use Firefox (most of the time) since SeaMonkey
> has a better design.
> 
> Has anyone tried this and does it work for SeaMonkey anyway?

Go Parent Folder works with Seamonkey 2.39. Open Tools → Add-ons Manager, "Search" for "Go Parent Folder" (or "Show Parent Folder") and "Install" it.
(In reply to romko.b.m from comment #132)
> (In reply to Tom Schneider from comment #131)
> > (In reply to Michael Schmitt from comment #130)
> > > While I don't agree that basic deficiencies should be marked wontfix just
> > > because someone wrote an addon to workaround them, the addon you're looking
> > > for is Show Parent Folder
> > > https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder/
> > > ?src=userprofile, not Go Parent Folder. They are by the same developer.
> > 
> > That's the wrong link for SeaMonkey, apparently.  Switch the word 'firefox'
> > to 'seamonkey':
> > https://addons.mozilla.org/en-US/seamonkey/addon/show-parent-folder/
> > ?src=userprofile
> > There one finds:
> > 
> > Not available for SeaMonkey 2.39
> > This add-on is not compatible with your version of SeaMonkey because of the
> > following:
> >     You need to be using Firefox 10.0 or higher.
> > 
> > Of course I do not want to use Firefox (most of the time) since SeaMonkey
> > has a better design.
> > 
> > Has anyone tried this and does it work for SeaMonkey anyway?
> 
> Go Parent Folder works with Seamonkey 2.39. Open Tools → Add-ons Manager,
> "Search" for "Go Parent Folder" (or "Show Parent Folder") and "Install" it.

Nice! It's a shame this simple code can't make its way into the main product core. I'd gladly trade "test pilot", "pocket", and "hello" for this.
(In reply to romko.b.m from comment #132)
> Go Parent Folder works with Seamonkey 2.39. Open Tools → Add-ons Manager,
> "Search" for "Go Parent Folder" (or "Show Parent Folder") and "Install" it.

Ok, I did that and they installed.  (I'm puzzled why the other method failed, maybe you could explain that.)

Upon opening the bookmarks I could not find a search window.  I looked up the help and it says:

> Searching the Bookmarks or History List
>
> To search the bookmarks list, begin from the browser window:
>
> 1. Open the Bookmarks menu and choose Manage Bookmarks. You see
> your Bookmarks window.
> 2. In the Bookmarks window, open the Tools menu and choose Search
> Bookmarks. You see the Find Bookmarks dialog box.

However, I don't see a 'Find Bookmarks dialog box'!  Is this a (severe) bug?  What could I be doing wrong?
I completely disagree about 'wontfix'.  How is a new user supposed to know that there is a plugin,
let alone one named obscurely 'go parent folder'?  They will not know that.  I never knew that
until this thread and I've been using SeaMonkey for years.  This really should be part of the standard
package of SeaMonkey!
(In reply to Tom Schneider from comment #134)
> (In reply to romko.b.m from comment #132)
> > Go Parent Folder works with Seamonkey 2.39. Open Tools → Add-ons Manager,
> > "Search" for "Go Parent Folder" (or "Show Parent Folder") and "Install" it.
> 
> Ok, I did that and they installed.  (I'm puzzled why the other method
> failed, maybe you could explain that.)
> 
> Upon opening the bookmarks I could not find a search window.  I looked up
> the help and it says:
> 
> > Searching the Bookmarks or History List
> >
> > To search the bookmarks list, begin from the browser window:
> >
> > 1. Open the Bookmarks menu and choose Manage Bookmarks. You see
> > your Bookmarks window.
> > 2. In the Bookmarks window, open the Tools menu and choose Search
> > Bookmarks. You see the Find Bookmarks dialog box.
> 
> However, I don't see a 'Find Bookmarks dialog box'!  Is this a (severe) bug?
> What could I be doing wrong?

Correction:  I don't even find 'Search Bookmarks' anywhere under Tools or other menus!
I have SeaMonkey 2.39.
Search Bookmarks is not in the Tools menu. It appears in the upper right corner as a field ready to fii in with your search request. It belongs to the menu bar of the Manage bookmarks screen. If there is no menu bar, try to locate the small triangle ▶ in the upper left corner. It opens the menu bar.
The "Go Parent Folder" has nothing to do with all that. It is contained in the context menu to each item in SIDEBAR (F9)
If you see no menu bar in "Manage bookmarks" screen, press Alt, you will see menu bar, then go to "View" an activate "Menu bar"
"Alt" is helpful !!
(In reply to Tom Schneider from comment #136)
> (In reply to Tom Schneider from comment #134)
> > (In reply to romko.b.m from comment #132)
> > > Go Parent Folder works with Seamonkey 2.39. Open Tools → Add-ons Manager,
> > > "Search" for "Go Parent Folder" (or "Show Parent Folder") and "Install" it.
> > 
> > Ok, I did that and they installed.  (I'm puzzled why the other method
> > failed, maybe you could explain that.)
> > 
> > Upon opening the bookmarks I could not find a search window.  I looked up
> > the help and it says:
> > 
> > > Searching the Bookmarks or History List
> > >
> > > To search the bookmarks list, begin from the browser window:
> > >
> > > 1. Open the Bookmarks menu and choose Manage Bookmarks. You see
> > > your Bookmarks window.
> > > 2. In the Bookmarks window, open the Tools menu and choose Search
> > > Bookmarks. You see the Find Bookmarks dialog box.
> > 
> > However, I don't see a 'Find Bookmarks dialog box'!  Is this a (severe) bug?
> > What could I be doing wrong?
> 
> Correction:  I don't even find 'Search Bookmarks' anywhere under Tools or
> other menus!
> I have SeaMonkey 2.39.

(In reply to romko.b.m from comment #137)
> Search Bookmarks is not in the Tools menu. It appears in the upper right
> corner as a field ready to fii in with your search request. It belongs to
> the menu bar of the Manage bookmarks screen. If there is no menu bar, try to
> locate the small triangle ▶ in the upper left corner. It opens the menu bar.
> The "Go Parent Folder" has nothing to do with all that. It is contained in
> the context menu to each item in SIDEBAR (F9)

(In reply to romko.b.m from comment #138)
> If you see no menu bar in "Manage bookmarks" screen, press Alt, you will see
> menu bar, then go to "View" an activate "Menu bar"
> "Alt" is helpful !!

What a nightmare! This is a good example of how NOT to set up a "user interface".
(In reply to romko.b.m from comment #137)
> Search Bookmarks is not in the Tools menu. It appears in the upper right
> corner as a field ready to fii in with your search request. It belongs to
> the menu bar of the Manage bookmarks screen. If there is no menu bar, try to
> locate the small triangle ▶ in the upper left corner. It opens the menu bar.
> The "Go Parent Folder" has nothing to do with all that. It is contained in
> the context menu to each item in SIDEBAR (F9)

None of these things exist!!!!  I am on Mac OS X 10.10.5.  Now what?
THE SEARCH BOX SHOULD BE VISIBLE AT ALL TIMES!
I don't recall what it used to be but I'm pretty sure it USED to be obvious.  maybe someone
wrecked it?
(In reply to romko.b.m from comment #138)
> If you see no menu bar in "Manage bookmarks" screen, press Alt, you will see
> menu bar, then go to "View" an activate "Menu bar"
> "Alt" is helpful !!

On Mac OS X 'Alt' does NOTHING.  Using it as a secondary key does NOTHING.
@all:
Please read <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>, do not abuse bugzilla.mozilla.org as a discussion/support/mail/whatever platform. All these "Missing 'Find bookmark'" and so on problems are well known and reported in other Bugs. If you need help how to use SeaMonkey please ask at <http://forums.mozillazine.org/viewforum.php?f=40&sid=1e47d19014a295e751ca69160d27b0ff> or nntp://news.mozilla.org/mozilla.support.seamonkey!
(In reply to Rainer Bielefeld from comment #142)
> @all:
> Please read <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>, do
> not abuse bugzilla.mozilla.org as a discussion/support/mail/whatever
> platform. All these "Missing 'Find bookmark'" and so on problems are well
> known and reported in other Bugs. If you need help how to use SeaMonkey
> please ask at
> <http://forums.mozillazine.org/viewforum.
> php?f=40&sid=1e47d19014a295e751ca69160d27b0ff> or
> nntp://news.mozilla.org/mozilla.support.seamonkey!

Those comments (and this one), are all feedback from your important "end users" and "testers", to provide feedback on the functionality as it relates to this bug, in order to provide the best possible product. Maybe it is time to review the documents you list, or take them down completely. All comments so far have been on target to the direct instructions on fixing the problem in this particular bug.
Re-opening, since an existing add-on isn't a reason for wontfix. If you want this to be wontfixed, you should bring this up with the mailNews owner.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Status: REOPENED → NEW
"Show Parent Folder" is an interesting add-on, but still pretty much useless in the following use case.

Let's suppose:
* I have a folder named "Travel bookings", old and full of bookmarks (ex: Skyscanner, Expedia...), itself being inside a huge tree of folders (ex: "Leisure > Travel > Travel bookings" and many others all around of course)
* I am visiting a new website (ex: HostelWorld) and want to add it straight and easily to the right folder

Method 1 (Firefox native):
* Browse through all my bookmark folders
* Open them one by one until I find the right one
* Drop my new "HostelWorld" bookmark there
How inefficient!

Method 2 (using an add-on):
* Search for a similar bookmark ("Skyscanner")
* Right-click "Go Parent Folder"
* Drop my bookmark
Faster, but still not user-friendly. Imagine if I were to REORGANIZE my bookmarks instead of adding just one!

Method 3 (proposed):
* Search for a similar bookmark OR a folder name (both would work!)
* Drop my bookmark straight away, as the bookmarks sidebar would immediately show every item matching what I looked for INSIDE their trees ("Leisure > Travel > Travel bookings > Skyscanner" among other results).

Is this too much to ask for? I really appreciate all the work having been done for years by the volunteers but I really hope this fix does get implemented over time, as bookmarking is becoming harder and harder the bigger your collection gets...
> Method 3 (proposed):
> …as the bookmarks sidebar would immediately
> show every item matching what I looked for INSIDE their trees 

In Seamonkey this is not the case: 
the bookmarks sidebar would NOT show NEITHER item matching what I "SEARCHED"(!!!) for INSIDE their trees
Somewhat unbelievable that this RFE has been around for 17 years and is still unfulfilled.

Stated work-around addons "Show Parent Folder" and "Go to Parent Folder" have been withdrawn by their respective authors and are no longer available.  

Yes, I am aware that you can open the searched-for bookmark in a new tab and use the bookmark-this-page "star" on the menu to fnd the containing folder.  However, this workflow pretty is pretty dreadful.

Any chance of getting this long outstanding RFE prioritized for a near term release?
(In reply to Dale Lobb from comment #147)
> Any chance of getting this long outstanding RFE prioritized for a near term
> release?
Unlikely, unfortunately, there is a lack of free hands even for critical release bugs, not mention about RFEs
I think they should take all the people working on things that aren't needed, like Pocket, Themes, and toolbar animations, and have them finally fix this infuriating oversight. They don't have their priorities straight, and that's why its been 17 years. Embarrassing if you ask me.
Assignee: nobody → bschwarze
Status: NEW → ASSIGNED
How can I generate correct patches for 2.53, 2.57... with mercurial?

https://hg.mozilla.org/releases/mozilla-release/rev/d4134557db7c
+
https://hg.mozilla.org/releases/comm-release/rev/47a22611c960
+ 580 patches from
http://www.wg9s.com/comm-253/ ?

or are there any current/complete repositories?
Flags: needinfo?(frgrahl)
Attachment #9013267 - Flags: review?
> How can I generate correct patches for 2.53, 2.57... with mercurial?

2.53 is still not an official release but a pet project on the way to 2.57. We discussed to add a 2.53 release branch later when the infra is ready. Curreltly it is just to add the mq patches. I can give you access to the git master which hosts the patches only.

Doing patches is outside of the bug. Just shoot me an mail or ask in the #seamonkey channel when I am there. You might also want to read the mdn guidelines first. See project page.
Flags: needinfo?(frgrahl)
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.