Open Bug 56418 Opened 25 years ago Updated 3 years ago

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

Categories

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

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

People

(Reporter: andre.jonsson, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: [2012 Fall Equinox])

User Story

From the many comments these seem to be the identified issues with the current imlementation:

1) In bookmarks search, a way to identify the folder path of a bookmark, or open the containing folder.

2) A way to search for folders (not just bookmarks).

3) While adding a bookmark, a way to find a folder within a (potentially large) folder hierarchy.

Usage example:  When adding a bookmark, one could use bookmarks search to locate some remembered similar pages, to identify an existing folder suitable for the new bookmark.  Then in the add bookmark widget, one could navigate to and select that folder.

Attachments

(2 files)

managing the bookmarks found after search
465 bytes, text/plain
Details
56418-AddFolderColumnToBookmarkSearch.patch
8.16 KB, patch
Details | Diff | Splinter Review
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: nsbeta1 → nsbeta1-
*** 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
Keywords: helpwanted, mozilla1.0
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.
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.
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: 10 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 → ---
Comment on attachment 9013267 [details] [diff] [review] 56418-AddFolderColumnToBookmarkSearch.patch This patch fell thru the roof because it had no reviewer assigned. But it seems to be a diff against the unpacked omni.jar. Could you redo it using either the comm-esr60 or patched up comm-release 2.53 source and set me as reviewer then.
Attachment #9013267 - Flags: review?

I noticed Firefox v69.0.1 has the same problem. :(

Based on the original RFE, the current "Open in Folder" button seems like an acceptable solution. Unless there are objections, I propose closing this issue and moving on to more fun stuff.

(In reply to Andy Wozniak from comment #154)

Based on the original RFE, the current "Open in Folder" button seems like an acceptable solution. Unless there are objections, I propose closing this issue and moving on to more fun stuff.

There is no "open in Folder" button that I can see. The issue occurs when one has a good number of bookmarks and searches for
a term. A list of bookmarks shows up. At that time, as far as I can see, there is no way to know which folder the bookmark is inside.
The issue is not solved for me.

The only current workaround I know of is the one mentioned in Comment #147: open the bookmark, then Edit This Bookmark (via the Bookmarks menu or by clicking on the bookmark star in the location bar. The Edit This Bookmark pop-up dialog has the current bookmark folder highlighted.

However, this method ONLY works if Firefox thinks that there is a current bookmark for the page that the bookmark leads to. Any difference at all, such as redirects, results in no match. And of course it doesn't work if the bookmark is a dead link. On my bookmarks there is only as 1% success rate, probably due to http:// redirecting to https://.

I don't know if this has been mentioned, but this particular RFE is the epitome of the problems with Firefox removing legacy extension support, for this reason: When Firefox was first announced, it's design goal was to strip away all the extra functionality in Communicator to the bare minimum. The justification was that needs could be met by add-ons. I've seen RFEs closed as Wont Fix solely because there was an add-on that satisfied the requirement, i.e. it didn't matter if the request that was for something that should be in the base product.

Now the add-ons that supplied that base functionality are gone, and can't be replaced because the new extension API is so limited. So, the entire justification for why Firefox never had necessary features is now flawed. If Firefox was going to remove the ability to add these features via the legacy API, then Firefox should either have added them into the base product or the new extension API should be as capable as what it replaced.

Just to be clear. This is a SeaMonkey bug. Was basically moved in comment 65 to our ui and product. We are happy to take a cleaned up patch for 2.53 and up.

SeaMonkey 2.53 and 2.57 still support xul classic add-ons too. If a Fx 56 add-on provided the functionality it can probably also be integrated. Just someone needs to do it and it needs to work with async places transactions.

Jeeze guys, this RFE was opened 19 YEARS ago.

Let me just add a little reminder of the original purpose of this request.

I believe I posted a predecessor to this bug, which would have been over 19 years ago. The earlier report was filed when the progressive "find" (^F) command in bookmarks was removed, in favor of "search". The find command scrolled the hierarchical bookmarks column to each match in turn. This allowed one to locate a bookmark that had been previously saved, in order to 1) save another bookmark in the same folder, or 2) find the related bookmarks one had saved in the same folder. My earlier report was (again, IIRC) retired in favor of this, as providing a folder column was considered functionally equivalent. It isn't, quite, because the folder hierarchy isn't visible, but it could be, if the folder column shows nested folders, e.g. top_folder/next_folder/inner_folder.

The main point, for me, is that without being able to find the folder containing a bookmark that I can find via title or some fragment of the URL, I am reduced to creating new folders for the same subject, over and over. On occasion, I try to find...by scrolling through folders...related folders, and dragging them together. But this is a hopeless quest, because I have...maybe several hundred thousand bookmarks.

I'm a bit embarrassed that I haven't managed to carve out time to help with this...

(In reply to Michael Schmitt from comment #156)

The only current workaround I know of is the one mentioned in Comment #147: open the bookmark, then Edit This Bookmark (via the Bookmarks menu or by clicking on the bookmark star in the location bar. The Edit This Bookmark pop-up dialog has the current bookmark folder highlighted.

Maybe I'm stupid, but there is no 'bookmark star' for SeaMonkey that I could see.
As far as I can tell, it's impossible to get the folder path of bookmarks.

The single name of the immediate containing bookmarks folder does not permit finding the folder for several reasons. First, it may be nested -- there may be multiple folders with the same name, distinguished by their parentage in the hierarchy. For example, in my bookmarks, "Security" could mean Security under Home, or Security under Technology Industry, or Security under Windows 10, or Security under Elections under Politics. Second, there is no "Search for folder by name" function, so even given the name, one would have to scroll visually through the bookmarks. And if one has thousands of folders...

"Go to folder" would work, though it might be nice if it did not replace the search results in the "All Bookmarks" search display. A folder column in the search results, even if it lists the folder path (I'm just realizing while writing this) would still need to be coupled with something like "Search for folder" or "Go to folder", else one still would need to visually scan for the folder. "Go to folder", along with an indication of the folder path in the search results, would be very very nice... The folder path would allow skipping irrelevant folders -- not having to "go to folder" only to find it's not where one wants to park a new bookmark.

Hmm...there's still a disconnect: When one is saving a new bookmark, one is not in the bookmark search window. Maybe I should describe How It Used To Be... See, there was a sidebar in which one could display one of several things, one of which was the bookmark hierarchy. When one wanted to add a new bookmark, one could use ^F (progressive find) to search for a folder name or a bookmark containing the search term, and then plunk the new bookmark in the selected folder. One would ^F one's way through til one found the right spot. Since I haven't seen this in some 20 years, I don't recall details. I am pretty convinced that ^F also searched bookmarks, not just folders, and that bookmarks were visible in the sidebar.

The point is that the point at which the folder-finding is needed (for me) is when one is bookmarking a page. So it seems the folder-finding mechanism would have to be available from the bookmark creation popup.

Speaking of the disappearance of extensions...one possible "workaround" might have been to open places.sqlite in SQLite Manager and do appropriate SQL queries. However, SQLite Manager did not survive the Great Extension Extinction.

2.49.5 here. There is no bookmark star in the Navigator location bar, but there is a bookmark icon. It is gray if the page is not bookmarked, colored if the page is bookmarked, and clicking it opens the "Edit this bookmark window". That pop-up window shows the containing folder and has a button on the right to expand and show the bookmark folder tree. I have no idea how does this play with bookmarks that are in more than one folder (I didn't test/try).

If this bug is for SeaMonkey only, then where's the open Firefox version of the bug?

The closest I can find is bug 196509, but it was closed 11 years ago as being a duplicate of THIS bug. I don't understand this. If you need separate bugs by product then how can a bug for one product be a bug for a product with a different code base?

(In reply to Michael Schmitt from comment #163)

If this bug is for SeaMonkey only, then where's the open Firefox version of the bug?

The closest I can find is bug 196509, but it was closed 11 years ago as being a duplicate of THIS bug. I don't understand this. If you need separate bugs by product then how can a bug for one product be a bug for a product with a different code base?

I meant "how can a bug for one product be a /duplicate/ of a bug for a product with a different code base?"

(In reply to Nuno Silva from comment #162)

2.49.5 here. There is no bookmark star in the Navigator location bar, but there is a bookmark icon. It is gray if the page is not bookmarked, colored if the page is bookmarked, and clicking it opens the "Edit this bookmark window". That pop-up window shows the containing folder and has a button on the right to expand and show the bookmark folder tree. I have no idea how does this play with bookmarks that are in more than one folder (I didn't test/try).

I have several hundred bookmarks, nested several folders deep. The bookmark icon you mention does indeed show up in SeaMonkey 2.49.4 so that when I am on a page with a bookmark it turns green. However, it only provides the deepest folder - so I still cannot find the series of folders which it is inside. Also, it is extremely awkward to have to go to a web page to see the folder and if the page no longer exists the folder information is not provided! This bit of code is useless and should be removed.

I think everything which needed saying has been said and just a fix is needed. I am restricting comments in the bug to users of the the editbugs group.

Restrict Comments: true

Updated the user story und unassigned the bug for now. bblack let me know if you want to continue working on it.

Not all the issues in the user story need to be resolved here :) We can always split and do follow-up bugs.

Assignee: ben → nobody
Status: ASSIGNED → NEW
User Story: (updated)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: