Closed Bug 196509 Opened 21 years ago Closed 16 years ago

Search for bookmark should show parent folder

Categories

(Firefox :: Bookmarks & History, enhancement, P4)

Product:
Firefox
Component:
Bookmarks & History
Type:
enhancement

Tracking

()

Status:
VERIFIED INCOMPLETE
Milestone:
Future

People

(Reporter: db1_1959, Unassigned)

References

Details

(Whiteboard: followup bugs in comment 91)

Attachments

(2 files)

Desirable behavior
57.89 KB, image/png
Details
Mockup of what should be added for 196509
105.13 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030308 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030308 Phoenix/0.5

When I search for a  bookmark, I want to know which folder contains it.
Easy to find  the duplicate bookmarks, if any.

Reproducible: Always

Steps to Reproduce:
1. Click Manage Bookmarks
2. Find window shows up, type in a bookmark
3. No parent folder seen for resulting bookmark results.
Actual Results:  
Nothing

Expected Results:  
Show both bookmark and parent folder
Just checked the behaviour in Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a)
Gecko/20030309 and there the parent folder is not listed, too.

Found a related RFE for Mozilla: see bug #56418, but I'm not sure whether
Phoenix uses the same code base here (though I guess so). Perhaps someone can
have a closer look and resolve duplicate if necessary.

- OS type set to "all"
- qawanted added
Keywords: qawanted
OS: Windows 98 → All
Erik, Phoenix and Mozilla don't share the same code for the bookmarks.

Anyway, this doesn't belong to build-config. -> Bookmarks.
Confirming for developer review.

Pierre, is this planned?
Assignee: bryner → chanial
Status: UNCONFIRMED → NEW
Component: build-config → Bookmarks
Ever confirmed: true
Keywords: qawanted
Summary: Search for Bookmark should show parent folder → Search for bookmark should show parent folder
I second this.  I want to use it to answer the eternal question, "where did I
file it"
Would this be solved by bug #171575 ?
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
As expected, this feature is also missing in both Mozilla branch and trunk
builds. This feature was present in Communicator when selecting EDIT -> Find in
Bookmarks. The search result was hilited under the folder that it was in.  
The Search function in Bookmarks should bahave as it always has in the past,
namely it finds the first occurance of a match and highlights it on the main
bookmark page, then F3 finds the next. If the user wants a new window with all
the matches, make it an option.
I agree as well.  BTW, it is a known bug that the context menu delete command will
 not work on "searched for" bookmarks.  It would seem plausible that this bug is 
the reason why so many people ask the question "where was this bookmark was 
filed?", because currently, they cannot delete the "searched for" bookmark 
directly.  While simply listing the containing folder would answer this question, 
it still wouldn't optimize the next step, which would be "What can I do with that 
information in Firefox, now that I know where it came from?"  Currently, you would
 have to traverse the entire bookmark folder tree to find this location. 
 My solution would be to fix the aforementioned bug, and then implement a "Manage Containing Folder" option similar to Windows Search's "Open Containing Folder"
 option, that would open the containing folder in a new Bookmark Manager window.

*** Bug 245498 has been marked as a duplicate of this bug. ***
Always wondered why not there, too. Would be a nice little usability addition so
you don't need to use Find every time.  
*** Bug 261816 has been marked as a duplicate of this bug. ***
Dupe of bug 171575?
leaving the decision for vlad.
Assignee: p_ch → vladimir
Depends on: 171575
Hardware: PC → All
*** Bug 270626 has been marked as a duplicate of this bug. ***
Assignee: vladimir → vladimir+bm
If you look at comment #7 -

we have Mozilla bug for that (but it does not deal with folders as this bug
starts) -
"Bookmark search should work as it did in Netscape 4" - bug 95748 -
and it's really critical - at my wor, having huge size Bookmarks, I _had to_ use
Netscape _4_! Other peope wrote the saem in commnets to 95748.

.
There is a lot of discussion in the forums on the need for this change.  Please
make this a high priority!!!  I see that this has been in this database for over
a year without resolution.

Here is an excerpt:
As Ander pointed out, "I have a ton of em" too.  The big problem is if you have
many nested folders you are unable to locate a specific bookmark.

This makes updating or adding additional bookmarks to specific folder impossible
unless you know exactly where it is within the collection

I have the same problem and wish there was a feature developed to address this.
When you search on a large base of bookmarks that are nested in folders you
can't figure out where the resulting bookmarks that are found are stored.  There
needs to be a 'properties' feature that displays the folder info. or a 'go to
bookmark folder' feature or go back to the way that Netscape 4 displayed the
found bookmarks.

Here are some URL's to the forum discussions:
http://forums.mozillazine.org/viewtopic.php?t=167602&highlight=bookmarks+manager+search+folder
Bookmark Search Lack - MozillaZine Forums
http://forums.mozillazine.org/viewtopic.php?t=167263&highlight=bookmarks+manager+search+folder
BOOKMARKS-management by far too primitive - SUGGESTIONS - MozillaZine Forums
http://forums.mozillazine.org/viewtopic.php?t=165080&highlight=bookmarks+manager+search+folder
Search bookmarks? - MozillaZine Forums
http://forums.mozillazine.org/viewtopic.php?t=100764&postdays=0&postorder=asc&postsperpage=15&highlight=bookmarks+manager+search+folder&start=15
Location of links/bookmarks (within the bookmark file)? - MozillaZine Forums


*** Bug 282690 has been marked as a duplicate of this bug. ***
1. I suggest that the current field labeld "Search" be renamed "Filter" as this
more accurately represents the current functionality of this FF feature.

2. For the benefit of those tracking and reading about this bug I have found a
somewhat inconvenient WORKAROUND so you can have true search capability on your
bookmarks and figure out where in the heiarchy it is stored.
Its so simple maybe you hadn't considered doing this:
Simply 'file, export' your bookmarks to a .html file on the desktop.
Then open the .html file with firefox by double clicking.
Now you can press control-F to do a find on the copy of the bookmarks file.

That workaround fails dismally when you have a reasonable number of folders,
sub-folders and sub-sub folders etc.  Trying to navigate to the parent folder (
is it 10 screens up or more ?)  is non-trivial.  
IMHO this does not answer the defect at all.  Full path or nothing !
I did say it was a "somewhat inconvenient WORKAROUND" as you have pointed out
the disadvantages when working with large bookmarks file hiearchies.
But at least it gives you something for now.
Hopefully the firefox developers will give us something much better in the future.
I would like to add a detail to this proposal: when searching for bookmarks
using keywords, I would like the name of the folders to be considered. So lets
say I have 3 bookmarks filed under "UML" but none of the bookmarks has UML in
its title or keywords. Searching for "UML" would match to those 3 bookmarks. How
this is displayed might prove to be a problem though...
I would be content if the search returned a list of folders first then list of
bookmarks second.  Whatever happens I am getting really frustrated trying to
figure out where I put some folder.  The simpliest solution is just to
right-click then view properties of a search result in bookmarks and it would
tell me the folder.  Even better is if I could click on it and the bookmarks
would switch back to tree view and navigate to that tree.  Thanks
Those of you watching this bug will be interested to know there's now an
extension to select the parent folder of a bookmark in the bookmarks manager.
It's a toolbar  in the bmmgr window. do a search, select the bookmark, then
click the "locate" toolbar button. the parent folder will be expanded and
selected in the sidepanel. 

Does the trick for me!

http://www.extensionsmirror.nl/index.php?showtopic=3264

--nato@bugzilla.r30.net
I love this extension!!!  Should have been a part of FF from day one!
Exactly what we needed to figure out where you are in large bookmarks files.
It does one other thing besides locating the parent folder.
It un-does the filtering affect of the search, highlights the parent folder and
puts you in the folder on top of the bookmark.
In other words, the display changes from a filtered view based on the search to
a normal view with the bookmark and its parent folder highlighted and you can
now view everything else in that folder even though it may not match the search.

This is exactly how I would want it to work.  Good job to whomever wrote this
extension!!!

(In reply to comment #23)
> Those of you watching this bug will be interested to know there's now an
> extension to select the parent folder of a bookmark in the bookmarks manager.
> It's a toolbar  in the bmmgr window. do a search, select the bookmark, then
> click the "locate" toolbar button. the parent folder will be expanded and
> selected in the sidepanel. 
> 
> Does the trick for me!
> 
> http://www.extensionsmirror.nl/index.php?showtopic=3264
> 
> --nato@bugzilla.r30.net


Sorry for the bugspam, but that extension doesn't work for me at all (running
Firefox 1.0 on Win2000); No locate button when searching, nothing new in the
right click menu when running a search, and customizing the toolbar buttons
doesn't show anything for a locate button. However, the extension is listed in
the installed extensions, and I have restarted the browser (at least twice). Is
there some sort of trick that I'm missing? Where exactly is the locate button
supposed to be? Or is this just a case of a buggy version 1.0 extension?
(In reply to comment #23)
> Those of you watching this bug will be interested to know there's now an
> extension to select the parent folder of a bookmark in the bookmarks manager.
> It's a toolbar  in the bmmgr window. do a search, select the bookmark, then
> click the "locate" toolbar button. the parent folder will be expanded and
> selected in the sidepanel. 
> 
> Does the trick for me!
> 
> http://www.extensionsmirror.nl/index.php?showtopic=3264

locate is nice ... up to a point.  One of those points is it doesn't work after
1.0 (or at least not with nightlies) - a frequent fate of extensions  Certainly
rather see this as part of base code. bug 171575 has a patch pending.

Removing dependency of bug 171575. Once 171575 is fixed we will know whether
this needs to live on or can be duped.
(In reply to comment #26)

> locate is nice ... up to a point.  One of those points is it doesn't work after
> 1.0 (or at least not with nightlies) - a frequent fate of extensions 

Locate works fine for me using FF 1.0.3.
I am using the released version, not any nightlies.

*All* parent folders (ie. grandparents etc) should be shown, rather than just
the immediate parent, to be useful for larger trees.
Assignee: vladimir+bm → nobody
How is this different from bug #56418 or bug #166234?  
(In reply to comment #29)
> How is this different from bug #56418 or bug #166234?  

1. the above two describe different issues - a closer reading is needed
2. note Bug 56418 comment 64 about bookmarks in the two products being different beasts. 
I see no reason that this valuable enhancement stays with Bookmark.

--> Places
Component: Bookmarks → Places
Priority: -- → P4
Target Milestone: --- → Firefox 2 beta1
(In reply to comment #31)
> I see no reason that this valuable enhancement stays with Bookmark.
> 
> --> Places

KL, owner + QA( on't automatically update when you chagne a bug's product+component.  It's probably generally a good idea to select "reassign bug ...".
QA Contact: mconnor → places
*** Bug 338662 has been marked as a duplicate of this bug. ***
*** Bug 339100 has been marked as a duplicate of this bug. ***
*** Bug 360815 has been marked as a duplicate of this bug. ***
The Locate in Bookmark Folders extension (https://addons.mozilla.org/en-US/firefox/addon/622) offers a workaround for this bug.
(In reply to comment #36)
> The Locate in Bookmark Folders extension
> (https://addons.mozilla.org/en-US/firefox/addon/622) offers a workaround for
> this bug.

It doesn't work for Places Bookmark.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070603 Minefield/3.0a6pre ID:2007060304 [cairo]

I'm not quite sure why making things easy to find and manage seems to take a back seat to cool features? Ease of finding something and then managing that something  trumps (in a very big way) a cool widget, which but the way usually leads to more stuff bookmarked which you can manage in the first place.

I would say that if the Mozilla Project were to take a serious approach to delivering a killer personal data management system (for FF and TB) (it must be operate with 4th grade ease of use) then the masses would be much more likely to make the switch.

my 2cents....

Seconded.  Could not agree more.

I now have zillions of bookmarks and I bet everyone else has.  Management of them is a huge headache.  Anything that make it easier is good.  This is one of 2 or 3 major requirememnts IMHO.  Other key reqmts include better sort features, and the ability to see dates when added, last accessed etc and to sort on those too.

We also need a tool (maybe it exists) to semi-automatically prune URL's that no longer work (eg by moving them to a 'dead' archive).
Target Milestone: Firefox 2 beta1 → Future
(In reply to comment #40)
> Seconded.  Could not agree more.
> 
> I now have zillions of bookmarks and I bet everyone else has.  Management of
> them is a huge headache.  Anything that make it easier is good.  This is one of
> 2 or 3 major requirememnts IMHO.  Other key reqmts include better sort
> features, and the ability to see dates when added, last accessed etc and to
> sort on those too.
> 
> We also need a tool (maybe it exists) to semi-automatically prune URL's that no
> longer work (eg by moving them to a 'dead' archive).
> 

In the meantime, a program called AM-DeadLink (http://www.aignes.com/deadlink.htm) partially solves the bug at hand, as well as your idea about finding all the dead URLs.  Hopefully it will be updated for the new Bookmarks file format.  

As far as dates added and last accessed, nope, that would have to be implemented in Firefox.
It looks like AM-DeadLink works on only Windows systems.-(
What happened to the plans to create an entirely new Bookmark Manager?  Many individuals contributed input regarding design at <http://wiki.mozilla.org/Bookmarks_Use_Cases>.  Several entries in that Wiki relate to this bug report (but none cite the bug by number).  
(In reply to comment #43)
> What happened to the plans to create an entirely new Bookmark Manager?  Many
> individuals contributed input regarding design at
> <http://wiki.mozilla.org/Bookmarks_Use_Cases>.  Several entries in that Wiki
> relate to this bug report (but none cite the bug by number).  
> 

The current UI designs are at:

http://wiki.mozilla.org/Places:User_Interface
I think the most user friendly way to solve this bug would be to implement search results like they did in opera - search result is just a filtered view of the bookmarks showing only bookmarks matching specified keyword along with the full folder structure they are in (it should match Comment #28 proposal); unfortunately such change in bookmarks manager does not seem to be planned.
I hope this bug will be solved in Firefox 3.0, that makes no sense not to solve it. I don't think that this will cause much effort.

Regards
Rudi
Hi all,

This is one of those things that are simple basic necessities. Without it, the bookmarks search seems unrefined (or incomplete). Opera does it out of the box.

There used to be an extension "Locate in Bookmark folders", but I do not think it is maintained any longer.

Currently, I am running Firefox3.0b5pre and the feature is still not there.
Attached image Desirable behavior — 
When one has thousands of bookmarks Firefox, categorized in folders, and we 
start typing a keyword on the bookmark sidebar then it starts 
isolating the finds. The problem with Firefox is that it gives us the 
matches in a *dry* list (we do not see the folder hierarchy).

Many times in order to keep things organized we would search for a 
bookmark which is similar in context (so that we can see which folder 
was used for that) and then place a new bookmark in that same folder.

Here is an example how it currently works in Opera (which perfect in 
contrast to Firefox 3.0b5pre)
Comment on attachment 310528 [details]
Desirable behavior

Sorry about the typo:
"Disirable" should be -> "Desirable"
Thomas just explained perfectly well the reason we need this feature.
I am testing Firefox 3.0b4 surprised that the "awesome new bookmark manager" still cant show me where my links are.

I really like Thomas' design proposal, but at a minimal, when you see the bookmark properties, just as it shows "Tags" it should show the local folder.
I know I shouldn't complain, especially since I don't have the skills to make this happen. But, I feel the team should know just how important search features and how it separates applications from personal toys and business class options.

I know of one very large government organization that recently switched back to MS O/E precisely because the employees went mad at the way they could not find things after switching a Firefox/Thunderbird (this goes for bookmarks AND email address books in Thunderbird)

Please - someone take this seriously! If you have hundreds of bookmarks, or email addresses stored across multiple address books (which is the way the TB import tools leaves a user in many cases), moving to Firefox/Thunderbird creates a very frustrating and unmanageable situation.

Just my 2 cents
I agree that this would be a nice feature, but you can find the location by doing a search for a bookmark and when you load this bookmark you can see in the Add Bookmark pop-up in what folder it is located.
(In reply to comment #54)
> I agree that this would be a nice feature, but you can find the location by
> doing a search for a bookmark and when you load this bookmark you can see in
> the Add Bookmark pop-up in what folder it is located.
> 

Yeah, I have done that a few times, but you have got to admit that that is going around your elbow to get to your thumb.  The most useful thing wouldn't even be showing the folder that contains the bookmark, but, instead, being able to right click it and choose to actually go to its real position in the tree.  Knowing the one folder that the bookmark is contained in can sometimes help, but often times, you want to know the folder hierarchy as well.
Or, say give us the one folder that it is contained in as one column, and also give us a column that contains the complete path, and make it clickable to actually go to any position on that path, like in Vista.
Sorry I have to remove my vote but I don't need the spam (removing cc: was not enough) - but I do want this feature.  Yes, there are all kinds of workarounds - documented ad nasuem for the former bookmarks manager - they are all a PITA.  

The good news is this bug's priority is P4 and there are only enh 5 bugs of higher priority:
bug 393509 P1 Mockup: Bookmark Contextual Dialog
bug 369919 P2 "Open All in Tabs" functionality for host and day containers
bug 331403 P3 Display the search scope (e.g. Current Collection Only) in the search field
bug 332629 P3 Change PlacesCreateFolderTransaction to make child transaction behavior more discoverable
bug 411598 P3 nsINavHistoryQuery lacks support for tags

The bad news is there are 125 other enh bugs and 730 non-enh.

Hopefully a resourceful soul will write an extension.
Wayne Mery,

The interesting thing is that all those higher priority bugs combined have less votes. I am wondering how much it takes for something to be noticed. (Do votes even matter at all ? ). Is 71 a good numbers ? should it 1000 ? 10,000 ?
The basic problem is that, once you have found a bookmark, the ability to do meaningful maintenance on the results is unacceptably limited.  The Delete and Cut functions are disabled while a search term is in the Search input area.  The Move Bookmark(s) function actually copies and does not move.  

Contrary to comment #54, when I want to maintain my bookmarks, I usually don't want to visit (load) the bookmarked Web pages.  

This worked well with Netscape 4.  Does anyone remember why this was changed?  

By the way, regarding comment #57, you can set your Bugzilla E-mail preferences not to send you messages relative to votes.  
(In reply to comment #59)
> This worked well with Netscape 4.  Does anyone remember why this was changed?  

That's Bug 171575.
I understand it was changed to be consistent with the search function in Windows Explorer that shows a flat list of found items (or the behavior of internet search engines).
RyuK, using the search funciton in Windows Explorer I can see the located folder in detailed-view mode. Also I can rigth-click on an item from the results and open the contained folder by the context menu. I dont't see the consistency with the windows explorer. 
Regards
Rudi
I agree with comment 61 ... the "open containing folder" of the windows search is one of the most useful things about it ... which is *exactly* what firefox is currently missing.
It is really necessary in my opinion to view which folder a bookmark is in, for all the reasons already expressed here.
Even if this lack is not going to drive me away from Firefox, it's a real annoyance.
Just adding my 2 cents, along with my vote for this bug...

As I'd finally wasted a half an hour telling the FF people about this most important feature, I get an e-mail to a thread that's over FIVE YEARS OLD.  A simple feature which could save users untold hours of searching and help them to even better organize their folders is long overdue.

My bookmarks go back over 13 years now. I'd have to spend months cleaning them up at this point.  A simple dead archive could solve that.  Further stats on the sites (last updated, quantcast rating etc.) could help you decide whether to dump the bookmark or waste countless hours visiting these sites.

My bookmarks aren't just bookmarks. They're an invaluable complex database of information on 3 careers and hundreds of interests.  The fact that I can't easily clean up this giant old mess in a day or two is unacceptable.  The programming's a snap.  It's 2008.  Time to end this thread.


Two extensions for Firefox 3.0 have been published.

1. Show Parent Folder( https://addons.mozilla.org/en-US/firefox/addon/7372 ) (In Sandbox)
Show Parent Folder in list view of Library. 

2. Go Parent Folder( https://addons.mozilla.org/en-US/firefox/addon/7377 ) (In Sandbox)
Right click Bookmark in list view shows "Go Parent Folder" context menu. And select the "Go Parent Folder" then Parent folder of the bookmark will be selected.
(In reply to comment #68)
Great work Alice!
I can confirm extension "Show Parent Folder" ( https://addons.mozilla.org/en-US/firefox/addon/7372 ) works for Linux users too   ;?)
Thank you Alice !
The "Go to parent folder" is exactly what I needed. It was that simple.
Was it too difficult to code ?

I still feel this should be included in the core program though.
(In reply to comment #70)
> Was it too difficult to code ?
It is small and simple code.

Because this expansion is an overlay, This must be rewritten for patches.
However, I do not know a source tree well.

Please write a patch.
(In reply to comment #71)
Do you plan to extend parent folder to column with full bookmark/folder hierarchy? Navigation in the left panel of the bookmark's Library would be fine too ;?)
I agree that this should be considered basic functionality. I like the idea of using focus in the left pane hierarchy to show the parent folder.
Flags: blocking-firefox3.1?
Not a blocker for 3.1, but we should get a plan to fix this.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
I'm just adding my approval to the many others who have stated that this functionality should have been included in FireFox.  This is NOT an add-on issue.  It is an oversight to not have included it.
There is one more thing I would like to add.  Those who are involved in FireFox development need to publicize the shortcomings of their browser, rather than hide them in the hopes that they will defer criticism.  As can be seen by the many posts to this issue, deferring criticism is a really lame strategy, and inhibits development.  Openness attracts those who might have solutions.  That is a flaw in developing anything, including this browser software, since the accountability of market driven forces has been removed.  That leaves, in this case, a cadre of "yes" people without the discipline inherent in market driven competitive environments.
Ideally, Firefox should have an option to export 
   a. Absolute Folder Name, 
   b. URL Name, and 
   a. Location 
from each bookmark from its database in a CSV format before it exits. Then the users can see the complete Bookmarks directory structure and search each spreadsheet column for data of interest, before editing Bookmarks.

Here my Super-SED/GNU sed script to extract the pertinent data from bookmarks.html file and save it in 'Search.xls' file, which can be opened by Excel or any other spreadsheet. It runs very fast even for very large bookmarks.html files.
This functionality should be incorporated in Firefox for Places, which replaces Bookmarks.html. If it too difficult to generate this spreadsheet at run-tine on demand, there should be an option to export a similar CSV database from Firefox Places database every time Firefox exits. Here is the script:
______________________________________________________________
#  Extract Absolute Folder Name, URL Name, and Location from each bookmark in the specified Bookmarks.html file
#  WARNING: The script must replace backslashes in the folder name with a "|" [or '`'] to preclude confusion
#  Replace each tab with a space.
#  A leading tab/space can be deleted.
/^ *<DT><A HREF=/{
 s/\t/ /g
 s/ *<DT><A HREF="\([^"]*\)".*>\([^<]*\)<.*/\t\2\t\1/
 s/^\t */\t/
 p
}
/^ *<DT><H3 /{
 s/\t/ /g
 s/.*>\([^<]*\)<\/H3>$/\1/
 H
 x
# replace backslashes in the folder name with a "|" to preclude confusion!
 s/\\/|/g
# remove trailing spaces
 s/\n */\\/g 
 p
 s/\\/\n/g
 x
}
/^ *<\/DL><p>/{
 x
 s/\n/\\/g
 s/^/   END OF /
 p
 s/^   END OF //
 s/\\/\n/g
 s/\n[^\n]*$//
 x
}
/^ *<HR>/I{
 s/ *<HR>/\t_________________________________________________________/i
 p
}
I've filed two follow up bugs for addressing this issue in the library window:

--Display folder in the prefpane. This would be similar to the Folder drop down in the star contextual dialog box, which is the same underlying code base as the properties pane in the Library (bug 469416)

--In folder in a column (bug 469421)

In general I think search in the bookmarks sidebar should be deprecated in favor of the awesome bar.
Like comment 1 suggested, this is a duplicate of bug 56418 - especially now that there the concern in comment 2 is no longer valid (phoenix and mozilla are one of the same).

The discussion in this bug has digressed a bit from the original issue.  I think Alex has the additional issues that were brought up filed, so I'm going to mark this as a duplicate.  Any additional issues should have a *new* bug filed.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Err, I realized just as I pressed commit that I got my bugs slightly backwards.  Bug 56418 is about SeaMonkey, and this is about Firefox (which both do have different code for bookmarks - *sigh*).

So, what this is really asking for is what bug 469421 was filed for.  There is a lot of benefit for whoever ends up fixing this bug to do the work in bug 469421 (it contains a summary of what should be done), so I'm going to forward duplicate this.

Any additional issues that weren't filed as follow-ups by Alex should still be filed as new bugs please.
An even more useful feature (except for finding duplicates) 
was the way search worked in netscape 4 (!) - the search results 
were shown within the normal bookmarks folder hierarchy, you could 
step through them and sub-folders were opened on demand.
I guess this would be a fine alternative solution of this issue.
(In reply to comment #83)
> An even more useful feature (except for finding duplicates) 
> was the way search worked in netscape 4 (!) - the search results 
> were shown within the normal bookmarks folder hierarchy, you could 
> step through them and sub-folders were opened on demand.
> I guess this would be a fine alternative solution of this issue.
That's bug 171575
Shawn, looking at comment #0 and especially the mockup screenshot of the desired behaviour (see attachment 310528 [details]), I don't see at all how this bug could possibly be a duplicate of bug 469421 (Add a folder column to search results for bookmarks in the library). 

If I understand correctly, this bug 196509 calls for a tree-view style representation of search results, i. e. rather than showing a flat list of results, the request is to show results visually embedded into their bookmark folder tree structure.
As opposed to that, bug 469421, as per its title, calls for adding a folder column to bookmark search results (in a table-style manner).
Even accepting that the underlying problem of both bugs might be the same, the suggested UI solutions are surely not the same; on the contrary, the visual and technical representation of search results is so much different that you cannot possibly say they offer the same functionality.

Consequently, this bug 196509 should be reopened with a more refined summary to avoid misunderstandings: "RFE: Implement tree-view style presentation for bookmark search results in library's search bookmark: show results within their parent folders". Better summary alternatives welcome, but imo this is much less ambiguous than the current "search for bookmark should show parent folder". Admittedly, the current summary might be misleading to point where one might think it's a duplicate of 469421.

Side note: Considering that you are also one of the driving forces to mark  Bug 171575 wontfix (Implement "find bookmark" in the same manner as Netscape 4.x), I can't help the impression that you are systematically closing down those bugs who advocate for a tree-view style representation of search results. However, closing down valid ideas that have more than 120 votes for them (81 votes for this one and 47 votes for the similar bug 171575, as of today) will not make such ideas disappear. It will make people feel even more frustrated and ignored.

Maybe I overlooked something, but I couldn't find any solid argument against the tree-style presentation of search results except for the fact that you don't want it (whether someone actually has the time to implement this is a different question). I don't care if "find bookmarks" works in the same manner as Netscape 4 which I can't really remember any more, but the casual manner in which valid ideas which many(!) people have been fighting for for years are just being closed down might easily be mistaken for disregard of others in a high-handed manner. The same impression might occur when people's preference for organizing their bookmarks in hierachical folders is just wiped away by saying things that sound like "why, we now have tags, why should we care about folders?" People who bother arguing it out in bugzilla's complex system, and people who even bother voting within that system in spite of all its oddities are certainly people who care and their ideas should be treated with all due respect.
The original poster's comment is very simple.  This is all he's asking for:  "When I search for a bookmark, I want to know which folder contains it."  That's not exactly a dupe of 469421; there are ways to "know which folder contains" a bookmark other than a parent-folder column in the tree -- a "show in parent folder" command for example.

Because the request was so simple, lots of people have interpreted this bug in lots of different ways.  The conversation above has generated many specific and diverging ideas.  If you commented here just to give your two cents, you've been heard.  If you have a specific idea, look for a bug that better fits it or file a new specific and targeted bug if an existing one does not exist, even if it's only to point to your comments here.  If the discussion can be broken up into its separate components, we can argue them individually instead of all at once in a giant mess.  Bug 469421 is a move in that direction.

Resolving incomplete.
Resolution: DUPLICATE → INCOMPLETE
@Drew.  Thank you!  I am the original poster, and you hit the nail on the head.
Status: RESOLVED → VERIFIED
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Here is a Photoshop mockup of what I believe the original poster of issue # 196509 has requested. At least it is what I would like to have added.
This bug has been closed, so it's probably not a good place for more comments and mockups. Among the relevant followup bugs are:

Bug 469421 - Add a folder column to search results for bookmarks in the library
Bug 469416 - Add "Folder" to the properties pane of bookmarks when viewing search results
Bug 469441 - Add "Open Enclosing Folder" to search results of bookmarks in the Library window (link to view/open containing folder, parent folder button)

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 for bookmark search results in the library proposed by bug 469421 and SM bug 56418. It also includes "View containing folder" button (bug 469441).
See Also: → 469421, 469416, 469441
Whiteboard: followup bugs in comment 91
This bug still exists in Firefox 10 Beta!
When the user searches for a bookmark of interest, there is no way to access it!
Bug exists in Firefox 33, please fix it. 
For example Google Chrome has this functionality for years (thanks to Safari? - I don't know).
This is becoming urgent!
With the advent of WebExtensions and the deprecation of other APIs add-ons like "Go Parent Folder" are being abandoned by their developers.
Such a basic requirement, various bugs about the problem, this should really become a high priority.
And Google Chrome can do it ("Show in Folder").
Bugs like this and being able to search on folder names (another bug is open for this) are absolutely critical to bookmark management.  And for many (nost?) of us, the ability to do easy bookmark management is a key differentiator.  Look how Chrome a year or more ago backed down ever so quickly when they tried to introduce a comic-strip style bookmark manager.  OK, they are still not doing what we all need, and neither is Firefox.  But both are so frustratingly close to being able to delivering a vastly improved bookmarking experience.  Please someone (who knows what needs doing) implement some of these suggestions.
@ Moz devs, this feature request has been made out to be way more complicated than it is - by both sides.
Imagine an OS file manager / browser, with search that finds file names, but never their location.  It'd be a big hit. :)

Just put in something, anything that somehow shows or gives option to view bookmark folder paths from search results.  Anything would be better than now - which is exactly nada.

Maybe ask Alice0775 White if you can use / buy / take over their code (update it for Fx 57) & make an optional addon, if after 15 yrs it's still too hard to integrate popup info or add another column. It doesn't look like Alice plans to maintain the addons.  He said it was simple code.

I / you can open the sqlite file & read the bookmark hierarchy.
Displaying data already in the DB.  What's so hard about that, if no one cares if the info displays perfectly, as long as it displays?

Maybe stop worrying so much about "what if our fix isn't perfect?"  Software is never perfect.
Maybe enlist help from advanced users; tell them what you need done & let them do some of the grunt work, if that's what it takes.

Thanks.
Nobody ever said it's hard, there's just no resources to do it. If the community wants to do it, someone should just come out with a solid plan and time to do it.
(In reply to Marco Bonardo [::mak] from comment #98)
> Nobody ever said it's hard, there's just no resources to do it. If the
> community wants to do it, someone should just come out with a solid plan and
> time to do it.

Well, it might not be hard to fix this - IF you know the codebase. Even if I am able to code I do not have the time to dig into the structure of the source code and learn the correct interfaces and so on.

If you see how much time was wasted for discussing this and "other" bugs on the same topic. In the mean time, social media integration was inserted to Firefox and removed again, just like other features. Test pilot projects are developed on and on....
[Tracking Requested - why for this release]:
Because Firefox 57 breaks the XUL-workaround-addon ....
tracking-firefox57: --- → ?
Hi! In general, we use tracking flags for release blockers, which are typically crashes, security issues, and severe regressions. I understand your frustration that this bug hasn't been fixed yet, and that it's no longer possible to work around this in 57. That said, Bugzilla isn't the place to voice that: we're already aware that this bug exists, we don't use "number of comments" to prioritize bugs, and leaving extended comments on an already long thread just adds noise. Thanks in advance for your understanding.
tracking-firefox57: ? → ---
Understood. But why not use "number of comments" as at least one of the metrics to prioritise?  I assume there are other metrics that merge together to give you a total priority score.  Just make this an additional feed.  It would seem to be sensible, rational and (at least partly) customer-driven.  What more is needed?
I second the opinion that this has been one of the worst omissions in Firefox from the beginning.
My workaround, as the addons that helped here are among the many not working in FF57+ anymore, building on comment 18:

go to Manage Bookmarks, Import and Save, Save as HTML;
open the resulting file in a decent text editor like Notepad++;
search for the name of the bookmark;
when found search again for "<H3" but with "backward direction" enabled.
This finds the previous header line, with the folder name on the right.
I use a very simple workaround that a) solves this 15-years-old issue, and b) doesn't require any of those pesky outdated extensions:
1. Use Xmarks to synchronize my bookmarks between Firefox and Chrome.
2. Use Chrome's Bookmark manager to search for some bookmark.
3. Right-click on the bookmark > "Show in folder".
4. Take note of where the bookmark is located.
5. Go back to Firefox and navigate to that folder.
Right there you have it: frictionless user interface to its maximum power.
( /sarcasm, obviously )
SADLY, I _actually_ have to do this when I want to manage more than a couple bookmarks in my collection.
> Does Mozilla still consider higher vote count bugs in some way? 
"Votes are not really used by Mozilla developers."  https://wiki.mozilla.org/BMO/UserGuide/BugFields#votes
I'm going to re-iterate comment 86: This bug diversified too much. We are tracking implementation for something similar to this in bug 469421.

Please do not comment there unless you are actually going to help with the implementation.

"+1" and "Firefox should have this" comments are not suitable for bugzilla, please read the etiquette before posting: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: