It would be useful to let you find a bookmark in the same manner as 4.x.

-> bookmarks

-> really bookmarks

-> 0.4, unless I do it earlier, as usual

As things stand right now, I cannot delete a bookmark unless I know where it exactly is. If I use the Find utility to find a bookmark, I should be allowed to delete the bookmark or alternatively, I should be provided with an option to locate the bookmark in the bookmarks tree so I can move/copy/delete it. As of right now, I can only Copy the bookmark.

Manoj, your comment doesn't add anything useful to this bug report. Please refrain from adding "me too" or advocacy comments to bugs. Unless you have some technical value to add to a report please refrain from commenting. Thanks.

The bookmark sidebar has a 'find' widget at the top. It seems to work. What else is needed to close this?

this bug is about implementing a find method ala ns4.x: by keeping the tree and selecting the matches one by one. I have it working, but there's a problem with the order results are shown: it can loop through the matches (folders open/close accordingly) but it does not follow the tree sorting yet, not even the natural one. I need more time to work on it.

depends on Jan's work on sorting the datasource itself. I will retarget this bug when his work will be landed

Re #6: > The bookmark sidebar has a 'find' widget at the top. The bookmark sidebar is not the Bookmark Manager window. Re #5: > Manoj, your comment doesn't add anything useful to this bug report. Huh? Didn't he provide a usage scenario (deleting a bookmark) and options for supporting it? > Please refrain from adding ... advocacy comments to bugs. So where should requirements information or usuability analysis related to specific design bugs be placed? Also, for areas with multiple design bugs (e.g., bookmark management), is there any central place for information of discussion, or does it just have to be attached to different bug reports with the hope that all design bug reports in that area would be consulted for any rework of the UI?

taking QA contact, sorry about the bugspam

*** Bug 216230 has been marked as a duplicate of this bug. ***

*** Bug 224909 has been marked as a duplicate of this bug. ***

pushing target milestone.

I don't remeber how Netscape 4.x did it, so here is my suggestion on how this could be solved: After performing a "Search", one is presented with a list of bookmarks that match the search criterion. The user will likely either want to "know" where the bookmark is located in his boomarks folders, or he will want to be able to "go there". Solution for "know": - Tooltip that shows path of bookmark (e.g., "Location: Bookmarks | Politics"). - New column that shows path. This column could be OFF by default, but turn ON while displaying search results. Solution for "go there": - selecting a bookmark and then clearing the search term maitain the selection and goes to the location of that bookmark. - add a context menu item: "Locate this bookmark". - Add a toolbar button: "Locate" (tooltip: "Locate the selected bookmark"). Should this toolbar button only be visible when search results are displayed? PS. I believe that bug 247466 and bug 196509 could be duplicates of this bug.

I don't know who first removed Netscape 4.x style search and implemented this search-engine-style results listing, but this search-engine-style listing takes O(n) where n is entire size of bookmark and takes up huge memory (DOM vs. SAX) at the first search, and traversing returned results is just painful. Who needs this feature for what reason? >Solution for "go there": >- selecting a bookmark and then clearing the search term maitain the selection >and goes to the location of that bookmark. >- add a context menu item: "Locate this bookmark". >- Add a toolbar button: "Locate" (tooltip: "Locate the selected bookmark"). >Should this toolbar button only be visible when search results are displayed? If it can be implemented, why doesn't it jump to a found item from the beginning? If Bookmark Manager has back/forward buttons a la browser window, you can go back to search results after you examine a specific item just like you do with a search engine, but you can't. BTW, comment #4 is covered in Bug 255255.

*** Bug 247466 has been marked as a duplicate of this bug. ***

. It's FireFox area but Mozilla also has exactly the same bug - "Current search is *useless*, better be as in Netscape 4" - bug 95748 - please read commnets there to understand the frustration of people (including me) who HAS TO use at work Netscape _4_ becasue we DO need normal search for our huge size Bookmarks! .

*** Bug 282227 has been marked as a duplicate of this bug. ***

Target Milestone: Firefox1.0 What's up with this bug these days?

I've implemented a patch that adds a "Show in tree" context menu item to bookmark search results. Clicking this cancels the active search, shows the bookmark tree, and selects the bookmark. If Firefox devs are interested in this, I'll be happy to polish up the patch and attach it. Otherwise, I'll probably release it as an extension. I believe this way is the best way to fix this bug, because it gives everyone the functionality they need without adding UI clutter. It also provides a workaround for bug 196509 and bug 255255.

This sounds like just what we need. Please let us know by posting to this thread whenever it either becomes accepted into the next version of firefox or if you release it as an extension so we can look for it. Thanks!! (In reply to comment #20) > I've implemented a patch that adds a "Show in tree" context menu item to > bookmark search results. Clicking this cancels the active search, shows the > bookmark tree, and selects the bookmark. > > If Firefox devs are interested in this, I'll be happy to polish up the patch > and attach it. Otherwise, I'll probably release it as an extension. > > I believe this way is the best way to fix this bug, because it gives > everyone the functionality they need without adding UI clutter. It also provides > a workaround for bug 196509 and bug 255255. >

This patch implements a "show in tree" context menu item on bookmark search results. As an added bonus, it also partially fixes bug 255255: An exception is no longer thrown when accessing the context menu, and properties of search results can be edited. Cut and Delete still don't work.

Yoni, I need a little help here. How do you install the extension that you attached here?

Re: comment 23 - This is a patch, not an extension. If the lead developers review it and check it in, it will be included in Firefox nightlies and in FF 1.1.

Comment on attachment 178832 [details] [diff] [review] implement "show in tree" The patch looks good, thanks! One concern I have is with special-casing the showintree command in bookmarksTree.xml, and just adding it to the end of the menu, etc. Not sure if that's a good plan from a UI perspective -- asking mconnor for sr, he may have some thoughts on this.

As of build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 1. Menu Item: Manage Bookmarks 2. Type string into search field. 3. Select one of the matching results 4. The "Delete" button lights up and is now no longer indicating "Deletion" of selected bookmark resulting from search can be deleted. 5. Pressing on the "Delete" button accomplishes nothing. 6. Right clicking on selected bookmark displays: cut, copy, paste, delete. 7. Selecting delete from the context menu accomplishes nothing. Thank you for such wonderful software despite these little annoyances.

(In reply to comment #26) > As of build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) > Gecko/20050317 Firefox/1.0.2 > > 1. Menu Item: Manage Bookmarks > 2. Type string into search field. > 3. Select one of the matching results > 4. The "Delete" button lights up and is now no longer indicating "Deletion" of > selected bookmark resulting from search can be deleted. > 5. Pressing on the "Delete" button accomplishes nothing. > 6. Right clicking on selected bookmark displays: cut, copy, paste, delete. > 7. Selecting delete from the context menu accomplishes nothing. > > Thank you for such wonderful software despite these little annoyances. Do you mean bug 255255 ("after searching bookmarks, the results are not editable")?

update summary, keyword

I'm inclined to disagree that this bug blocks bug 196509. bug 196509 is about SEARCH. This bug is about FIND. Can the person who marked it so explain? Am I missing something?

What is the difference between "search" and "find"? This bug and the other bug seem to me to be about the same problem: searching for bookmarks gives a list of results, but you can't actually manipulate those results or discover where they are in the bookmark hierarchy.

(In reply to comment #30) > What is the difference between "search" and "find"? > This bug and the other bug seem to me to be about the same problem: searching > for bookmarks gives a list of results, as you say, SEARCH provides a list of results. FIND is not the same - it positions at first (or next) occurrence, ala Netscape 4.x behavior, within and showing the tree structure. > but you can't actually manipulate those > results or discover where they are in the bookmark hierarchy. neither of these bugs is about editting - editting is bug 255255.

(In reply to comment #29) > I'm inclined to disagree that this bug blocks bug 196509. bug 196509 is about > SEARCH. This bug is about FIND. > > Can the person who marked it so explain? > Am I missing something? Rather I think Bug 196509 is a dupe of this bug. But hey, the comments in Bug 196509 that suggest so seem to be ignored.

(In reply to comment #32) > (In reply to comment #29) > > I'm inclined to disagree that this bug blocks bug 196509. bug 196509 is about > > SEARCH. This bug is about FIND. > > > > Can the person who marked it so explain? > > Am I missing something? > > Rather I think Bug 196509 is a dupe of this bug. But hey, the comments in Bug > 196509 that suggest so seem to be ignored. I also think that the two bugs mentioned afore are very close to duplicates. They are both after the same result but define the problem differently. For this reason I don't think they should block each other, rather they support each other. You fix either one and you should kill both birds. More importantly, for anyone reading this bug that hasn't read bug 196509, an extension has been developed that gives me exactly what I wanted and fixes both of these bugs for me. See https://bugzilla.mozilla.org/show_bug.cgi?id=196509#c23

Comment on attachment 178832 [details] [diff] [review] implement "show in tree" This definitely shouldn't go at the end, Properties goes at the end of any context menu I've ever seen it in. I haven't really looked at what builds the context menu for bookmarks recently, but it makes more sense to implement something that drops the disabled items and adds this in an appropriate place when a search is occuring. If I'm totally missing something wrt to this, please enlighten me.

Changes from previous patch: 1. Menuitem location is now determined by BookmarksCommand.getCommands (like other menuitems). The controller's supportsCommand method is used to determine which items are shown in the menu. 2. When using this in bookmark manager, reset the left (folder) pane to the root item. 3. Fix preexisting bugs related to the combination of the folder view and search in bookmark manager. These bugs also affect the 'show in tree' feature. For example: select a folder, perform a search, select a second folder, and cancel the search. Result: the first folder's contents are shown while the second is selected.

*** Bug 307490 has been marked as a duplicate of this bug. ***

vlad, is there a reason why review is being held back on patch v2? is this function still applicable when the new "places" functionality drops in?

*** Bug 330933 has been marked as a duplicate of this bug. ***

(In reply to comment #37) > is this function still applicable when the new "places" functionality drops in? This feature should be considered for Places now that it's unlikely that it makes it to the old bookmark...

Comment on attachment 186409 [details] [diff] [review] patch v2 this patch is no longer relevant

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 #41) > 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 in the trunk build.

What is the use case for this now? I can't think of a convincing one, which means I'm inclined to say that this bug is WONTFIX.

In Firefox 3.0.4 from the Awesome Bar and in the Bookmark Manager in the Search Bookmarks field, it is still not possible to locate or edit a bookmark. A "locate" use case is when the user wants to find a misplaced bookmark to put it from the incorrect folder into the correct folder. To do this, he needs to know in which folder the found bookmark is in. An "edit" use case is when a user wants to retroactively add a tag to bookmarks that match some search criteria (e.g., "Obamania" or "FSM"). Please remove the Whiteboard: CLOSEME JAN 11.

(In reply to comment #45) > A "locate" use case is when the user wants to find a misplaced bookmark to put > it from the incorrect folder into the correct folder. To do this, he needs to > know in which folder the found bookmark is in. And I'm not convinced that this is a use case we need to support. > An "edit" use case is when a user wants to retroactively add a tag to bookmarks > that match some search criteria (e.g., "Obamania" or "FSM"). This is incorrect, at least in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20081211 Shiretoko/3.1b3pre. As far as I know, no UI changes have been made there since 3.0 either.

FWIW, I agree wholeheartedly with the sorely missed "locate" scenario from comment #45.

Shawn, just that I know how this works here: How can we "convince" you? Ever since NS4.7n I miss the chance to know where both are: Bookmarks and folders, the former i can find but not locate, the latter I cannot even search for anymore (bug 292104). I would like to group bookmarks of a research session in one folder, so later I can find stuff by remembering one link/site, searching for it, and finding all others in the same folder. For this to work, I obviously need to know where in my hierarchy a certain found bookmark is located, and i feel FF should come with such a feature. Finding folders goes along with this - ppl build and model taxonomies of their web experience in bookmarks, but as long as whole folders cannot be found and (!) located within a hierarchy, users unfortunately cannot benefit from their modeling to a full extent. Maybe it helps to think of bookmarks as files in a filesystem? Many of us would like to be able to do most of the things a tree view of a file system (better: the different tools all OSes/GUIs currently in use) allows us to do.

(In reply to comment #48) > Shawn, just that I know how this works here: How can we "convince" you? An argument that demonstrates that this is a feature that will be beneficial to a majority of our users and not just a small percentage. It should be noted that I won't close this without discussing it with one of our user experience folks as well. > I would like to group bookmarks of a research session in one folder, so later I > can find stuff by remembering one link/site, searching for it, and finding all > others in the same folder. For this to work, I obviously need to know where in > my hierarchy a certain found bookmark is located, and i feel FF should come > with such a feature. Tags easily accomplish this. Yes, tags are fairly new to Firefox (less than a year), and yes, it may be true that some people aren't familiar with tags, but constantly supporting old behaviors means the code gets more complex and harder to test which increases the likelihood of regressions being introduced. The fact that this bug has been open for six years and only has 32 votes indicates that it's not a big issue for most people.

(In reply to comment #49) > (In reply to comment #48) > > Shawn, just that I know how this works here: How can we "convince" you? > An argument that demonstrates that this is a feature that will be beneficial to > a majority of our users and not just a small percentage. It should be noted > that I won't close this without discussing it with one of our user experience > folks as well. > > > I would like to group bookmarks of a research session in one folder, so later I > > can find stuff by remembering one link/site, searching for it, and finding all > > others in the same folder. For this to work, I obviously need to know where in > > my hierarchy a certain found bookmark is located, and i feel FF should come > > with such a feature. > Tags easily accomplish this. Yes, tags are fairly new to Firefox (less than a > year), and yes, it may be true that some people aren't familiar with tags, but > constantly supporting old behaviors means the code gets more complex and harder > to test which increases the likelihood of regressions being introduced. > > The fact that this bug has been open for six years and only has 32 votes > indicates that it's not a big issue for most people. Not necessarily. There are only 11 Firefox bugs still open from that far back, and this bug is actually the second most voted on bug out of those. The only other one that has more votes is Bug 171082. People generally will only vote on things that specifically impact them, and things that are as general as this they may not have decided to, but would still like to have it. Notice that since you specifically mentioned voting on this, 17 more people have voted! Back when this bug was created, people didn't have a limitless number of votes, and so they probably just CC'ed themselves.

> And I'm not convinced that this is a use case we need to support. so if a file search in an os of your choice refused to give you the location of the file, that would be acceptable? The bookmark manager search is primarily for organizing bookmarks not just opening them. And to organize you need the location.

(In reply to comment #49) > (In reply to comment #48) > > Shawn, just that I know how this works here: How can we "convince" you? > An argument that demonstrates that this is a feature that will be beneficial to > a majority of our users and not just a small percentage. If we only keep features that are used by a "majority" of users, we would be using Google's Chrome. This bug is something that is highly frustrating when one needs to manage bookmarks (it's like running into a brick wall). > It should be noted > that I won't close this without discussing it with one of our user experience > folks as well. That's good to hear. Thanks. Yet another use case is: User had bookmarked an important address in the past and forgot where he put it. The address's title and URL don't contain much useful information(*). User spends a bunch of time with various search terms and finally finds the bookmark. He wants to either see what folder it is in (to move it to a place he can better find it next time) or add info to the title or tags (to better find it via search next time). With this bug the user can neither see where the bookmark is located nor can he edit it. It's a frustrating dead-end. (*) BTW: This makes the Awesome-Bar useless too. > The fact that this bug has been open for six years and only has 32 votes > indicates that it's not a big issue for most people. It might be interesting to estimate the proportion of the number of total Firefox users to the total number bug voters. I wonder how many of millions of users these 32 votes translate into...

(In reply to comment #51) > so if a file search in an os of your choice refused to give you the location of > the file, that would be acceptable? That is a false analogy. A bookmark manager may have similarities to a file manager, but in this case your analogy is an informal fallacy for this argument. It's also an ignoratio elenchi because it has nothing to do with implementing find bookmark like Netscape 4.x did. (In reply to comment #52) > Yet another use case is: > User had bookmarked an important address in the past and forgot where he put > it. The address's title and URL don't contain much useful information(*). User > spends a bunch of time with various search terms and finally finds the > bookmark. He wants to either see what folder it is in (to move it to a place he > can better find it next time) or add info to the title or tags (to better find > it via search next time). With this bug the user can neither see where the > bookmark is located nor can he edit it. It's a frustrating dead-end. As I said in comment 46, you can edit all that information in the current search option. I've just verified that this is also the case for Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4. So that means the only thing you cannot do now is know what folder the bookmark is in. If that's the case, what you are really looking for is bug 56418. In fact, bug 56418 comment 96 even offers some addons that would solve your problem. This particular bug is about finding bookmarks just liked Netscape 4.x did. I'm making the argument that we don't want to do that, but that there still may be usability issues which are /not/ this bug.

> It might be interesting to estimate the proportion of the number of total > Firefox users to the total number bug voters. I wonder how many of millions of > users these 32 votes translate into... I just checked, and the previous comments were off, because this bug is now tied for 11th place in open Firefox bugs ranked by votes, so it actually has a lot of votes.

(In reply to comment #53) > As I said in comment 46, you can edit all that information in the current > search option. You're right! I was only looking at the context menu (where "Properties" should also be) and forgot about (and didn't even notice) the edit fields at the bottom. :-[ > So that means the only thing you cannot do now is know what folder the bookmark > is in. If that's the case, what you are really looking for is bug 56418. In > fact, bug 56418 comment 96 even offers some addons that would solve your > problem. Showing only the parent folder is a big step in the right direction. Showing the whole folder path would be the better solution - especially if the parent folder's name is generic and used multiple times. Anyhow, it's only an add-on; it should be built-in. > This particular bug is about finding bookmarks just liked Netscape 4.x did. > I'm making the argument that we don't want to do that, but that there still may > be usability issues which are /not/ this bug. I've already described some usability issues. I can't remember how Netscape handled this anymore because it's been so long ago, but the issues I and everyone interested in this bug have should be addressed. BTW: IIRC you have never explained *why* "we" don't want to fix this bug. Where's the downside?

If the following add-on were put into the default code, I think most of us would be very happy: Go Parent Folder https://addons.mozilla.org/en-US/firefox/addon/7377 (The add-on and the context menu item should be called "Go to Parent Folder")

As filed, this is WONTFIX, we're not going to do this like NS 4.x. There's a problem here, but this is not the right solution.

(In reply to comment #55) > Showing only the parent folder is a big step in the right direction. Showing > the whole folder path would be the better solution - especially if the parent > folder's name is generic and used multiple times. Anyhow, it's only an add-on; > it should be built-in. That's still not this bug... > I've already described some usability issues. I can't remember how Netscape > handled this anymore because it's been so long ago, but the issues I and > everyone interested in this bug have should be addressed. And they still aren't this bug either... > BTW: IIRC you have never explained *why* "we" don't want to fix this bug. > Where's the downside? I thought it was clear, but I'll be happy to reiterate. We've made a lot progress with bookmarks and searching since this bug has been filed. I don't think we want to throw away all those improvements and implement things like Netscape 4.x did. With that said, we should be filing smaller-scoped bugs on usability issues that are still present that should Netscape 4.x did. (In reply to comment #56) > If the following add-on were put into the default code, I think most of us > would be very happy: Then you should file a bug to get a context menu added and post that bug here. It's not *this* bug.

I don't have a solution - sorry. And I'm not pining for the 4.x days. But I'm sure there's a good percentage of dedicated users who have so many bookmarks it's hard to manage, would have welcomed something better 3-4 years ago, we just work through the pain and live with it. I for one don't understand why this was so strongly resisted years ago - but we're past that point. I'm sure there's a good reason there isn't a groundswell of interest. Perhaps the average joe/jane either - has so few bookmarks, - is so well organized - or has such a good memory they don't care. And there are probably pack rats who have too many for their own darn good. I last looked at the addon space a year or two ago none of them measured up, and a quick look today doesn't look like much has changed. Perhaps it is indeed time to move on - get rid of folders and really make the problem go away. Run everything through tags. Seriously

Hi. I would like to take part of this discussion. I've been notified that this bug was marked as WONTFIX. It amazed me. I really agree with Tobias Hofmann when he writes: (In reply to comment #48) > I would like to group bookmarks of a research session in one folder, so later I > can find stuff by remembering one link/site, searching for it, and finding all > others in the same folder. I pass an enormous amount of time doing searches on the web. My Firefox bookmarks are for me an essential working tool, but unfortunately Firefox lacks some bookmarks management features. I've collected thousands and thousands of bookmarks over years, classified into folders, often into research session folders. If I do a search about "aSubject", I will often mark all interesting tabs into a research session folder named for example "aSuject and some relevant keywords". In the folder description, I would like also to put some words about this current research (for example: date, context, sub-topic to deepen, etc.), but it's a bit useless because I'm just not able to search into folders description. I would like to be able to localize easily my research session folder to take back my research with the tabs it contains. I've been waiting for years for a Firefox improvement about its bookmarks management. I just don't understand why we're able to "folder" our bookmarks but not able neither to localize them nor search folders name/description. I really feel like this: "we just work through the pain and live with it" (see the comment #59 from Wayne Mery). For a long time, I was opening my bookmarks.html file to do a dirty search with Ctrl+F... I don't want to complain in a non-constructive way, but the bug 196509 (Search for bookmark should show parent folder) depends of this current bug, and to know that the latter won't be fix disappointed me a lot. Bookmarks folders are just like file system folders: a tool to organize a mass of information. I have on my /home tens of thousands of files and I organize them with folders. Fortunately I'm able to search them. I would just need to do the same thing with my everyday working tool, i.e. my Firefox bookmarks.

I think there might be a mis-communication between marking this bug WONTFIX (which is always politely in all capital letters),and enabling the use cases that people are interested in for managing their bookmarks. So if re-implementing the UI of Netscape 4.x is what we are not going to do, here is what I think we should do: Going from bookmark to parent folder: -Display the folder of bookmarks when searching in the Library in two different ways: --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 a column (bug 469421) Going from parent folder to specific bookmark: -Allow the user to search for folder names in the Library window (bug 406157) -Allow the user to find bookmarks based on folder names in the awesome bar, in a similar manner to how we currently search tags (bug 469425) -Allow the user to navigate on tags and folder names in the awesome bar (bug 469424) All of this is being tracked with the meta bug 469426

One more: bug 469441, Add "Open Enclosing Folder" to search results of bookmarks in the Library window

(In reply to comment #53) > This particular bug is about finding bookmarks just liked Netscape 4.x did. > I'm making the argument that we don't want to do that, but that there > still may be usability issues which are /not/ this bug. (In reply to comment #57) > As filed, this is WONTFIX, we're not going to do this like NS 4.x. There's a > problem here, but this is not the right solution. The problem exists for a couple of weeks, just around 300, so not too long for software >:-( After around 250 weeks, the original request became inacceptable for Shawn and Mike (that way I understand you) but not the others who wonder about WONTFIX. Anyhow, the problem still persists, as even you both admit - so please go ahead and suggest a "right solution" convincing us others!! In the quoted bugs I was unable to find one. The mentioned addons are nice - here are my personal top 4 why they cannot sufficate 1) I have 6 bookmarking addons installed. Guess, how sufficient native FireFox bookmarking management is :-( even for a not too heavy user like me 2) The addons reduce the pain, but still do not allow as powerful & convenient bookmark management as with NS4 or even Mosaic! Several use cases metionend in this and related bugs are not supported. 3) I don't have the addons on all computers (e.g. work, customers, internet cafe, family, friends - on several computers usb drives are disallowed so portable firefox impossible) 4) Addons are not available constantly. 5 out of the 6 addons do not work with FireFox 3. FF3 does not support several of my use cases. Hence, I'm still on FireFox 2. Yes, that's the only reason. So improving the standard bookmark management is better than forcing users to re-search addons for every new major version of the browser. /Georg

(In reply to comment #53) > (In reply to comment #51) > > so if a file search in an os of your choice refused to give you the location of > > the file, that would be acceptable? > That is a false analogy. How is that a false analogy? We put similar files in the same directory (or "folder") so that when we go to one file (e.g., clicking an icon in a folder window, or using cd and some file-editing command), we are "close to" the similar files (we don't need to re-open the window or repeat the cd command). You can search for a file (by simple name or contents) and get to the directory it's in (GUI folder for window or file pathname for textual environment). We group similar bookmarks into folders so that when we go to one bookmark (in the relevant usage modes (editing, finding similar ones by how we grouped them)) we are close to similar bookmarks. In the Netscape 4.x GUI, you could search for a bookmark (by bookmark title, URL contents, or description contents) and get to the representation of its containing bookmark folder (a portion of the tree control showing the bookmark hierarchy). So how are bookmarks and bookmark folders not analogous to files and directories? (The differences in uniques of names and the related preservation of order don't break the analogy above.) Whether or not the GUI looks/work like Netscape 4's GUI, SeaMonkey/ Firefox needs an interface that lets users combine (most) individual bookmark operations with navigating around the bookmark hierarchy. > (In reply to comment #52) > > Yet another use case is: > > User had bookmarked an important address in the past and forgot where he put > > it. The address's title and URL don't contain much useful information(*). User > > spends a bunch of time with various search terms and finally finds the > > bookmark. He wants to either see what folder it is in (to move it to a place he > > can better find it next time) or add info to the title or tags (to better find > > it via search next time). With this bug the user can neither see where the > > bookmark is located nor can he edit it. It's a frustrating dead-end. > As I said in comment 46, you can edit all that information in the current > search option. From there, can the user move it to a folder that is nearby in the bookmark hierarchy? (Can the user even move it up or down (re-order it) within its immediately containing folder?) > This particular bug is about finding bookmarks just liked Netscape 4.x did. > I'm making the argument that we don't want to do that, but that there still may > be usability issues which are /not/ this bug. Which part of that (finding bookmarks as in Netscape 4) are you saying we don't want to do? (Are you just talking about details of the UI?) Daniel

(In reply to my own comment #63) > 2) The addons reduce the pain, but still do not allow as powerful & convenient > bookmark management as with NS4 or even Mosaic! > 4) ...FF3 does not support several of my use cases... Today, I spend some time with FF3. Yes, tags introduced some nice possibilities. Still, the above two points hold true - there are some usability or functional flaws/gaps concerning bookmarks in comparision with ancient NS4. I think my observations could be of interest in the context of the discussion here. - in bookmark sidebar and in organize bookmarks, the search does neither crawl bookmark description field nor folder name / description (see Bug 265048 and links to other bugs) - in bookmark sidebar, after a search the search result neither shows tags (see Bug 405549) nor the containing folder (also not in "properties"). Hence, it is impossible to a) find and b) create silbings (e.g. a newly found firefox extension shall be files as all other extensions). See bug 470117 for details. - add bookmark lacks some bookmark property fields. It does not offer to add description or keyword - this requires the add on "Add Bookmarks Here²". This is OK for me, even though I wonder whether I am the only person using descriptions e.g. to note bookmark related hints or additional infos. I hope it got clear: I do not want to have bookmark handling exactly as in NS4, but do I neither want to loose functionality that I already had! For me "It would be useful to let you find a bookmark in the same manner as 4.x." is more about the possibilites and less about copying exactly the UI. /Georg

This is a great example of the arrogance sometimes on display in open source projects. This is a *REAL* problem, and it has positively sucked for six years now. Just marking it "WONTFIX" is ridiculous. This bug should still be outstanding - I add my voice and vote to this as the single most important Firefox bug there is. While tags might be nice for new things, they still do absolutely nothing to solve the basic problem of simply *finding* the location of an already existing bookmark! This problem is a HUGE barrier for the small but significant number of us that have thousands and thousands of bookmarks, especially if there are hundreds of folders that may have the same organizational structure inside them - the need is for a complete path view not just "folder above". In my case, those bookmarks are my most valuable resource, literally cataloging over a decade of R&D hunting across hundreds of disciplines. The fundamental point here is THE HEIRARCHY *ITSELF* EMBODIES VALUABLE CATEGORIZING INFORMATION - you are advocating something like what iTunes does that infuriates so many people - a "flat" view of the world that completely ignores the very valuable information implicit in the hierarchy. Tags are nice, but they are no substitute for nested hierarchy. "Googling" tags is not the answer to every problem! As Georg reported, I too am forced to FF2 for bookmark management - This is a real pain, since I use FF3 to browse, then have to e-mail links to myself so I can bookmark them on my home computer using FF2, which at least supports the "Locate in Bookmark Folders" extension. Also, as several have noted, the current FF3 bookmarking is a huge step backwards in functionality from what we all had a decade ago. Like many, I use several older extensions to plug the gaps. Bookmarks in FF3 are completely useless to me - I don't even bother to bookmark in FF3 since its entire bookmark scheme is so brain-damaged. FIX THIS BUG!!! CALLING IT "WONTFIX" IS BOGUS AND IGNORES THOSE THAT HAVE BEEN WAITING YEARS FOR A FIX TO THIS VERY REAL BUG!

The Party has decided that hierarchies are not communist as Mozilla pretends to be; "This bug is WONTFIX for the good of the code!" I WOULDFIX, if they let me. Until then i just bookmark my HTML bookmarks, and search in that... but that's impossible now without exporting before each search.

(In reply to comment #67) > I WOULDFIX, if they let me. If you're able and you want to implement a better bookmarks management through an extension, let's go. I think there are lots of people who would benefit from such an extension.

This would be an absolutely great project considering all the trouble that has been reported with Firefox 3 bookmarks. I would assign gold stars to every contributor (like they do in the cygwin community, virtual stars, actually). Is there a suitable forum to discuss how such an add-on should look like? (I'm not sure whether this is the right place.) Some initial thoughts: - The add-on should provide full bookmarks management and a full set of user interface features (including separate bookmarks manager window or side-bar, up to user preference), so to replace internal bookmarks completely - The add-on should use the traditional HTML format (preferably stored in a reasonable location, not a cryptic profile subdirectory) - Bookmarks management must be reliable and fast - Adding "tags" might be worthwile - Consider https://bugzilla.mozilla.org/show_bug.cgi?id=469426 - Consider https://bugzilla.mozilla.org/show_bug.cgi?id=404983 - Favicons should simply work (in contrast to Firefox 2) - ...?

Bookmarking and navigation are essential browser features. I think that Firefox shouldn't need crutches. Bug 56418 agrees. I think this parity bug is a valid RFE. Is the problem that the bookmarks database doesn't store hierarchy information?

I've opened a discussion in getsatisfaction.com about Firefox bookmarks management: http://getsatisfaction.com/mozilla/topics/why_were_not_able_to_search_all_bookmarks_information Feel free to participate.

(In reply to comment #71) > I've opened a discussion in getsatisfaction.com Why not have the discussion "closer to home": news://news.mozilla.com:119/mozilla.dev.apps.firefox

(In reply to comment #69) > Is there a suitable forum to discuss how such an add-on should look like? > (I'm not sure whether this is the right place.) Hi. What about the creation of a website dedicated to this subject? I think that it would put together all the ideas, permitting to realize the appropriate add-on the more rapidly possible. I've been waiting for years for a bookmarks improvement, but I start to think now that Mozilla won't do anything about that.

Are people simply seeing the resolution of this bug and completely failing to actually read the comments in it? Specifically, please take a look at Comment 61 and Comment 62 where a number open bugs are linked to for issues that have been brought up in this bug.

>Why not have the discussion "closer to home": > >news://news.mozilla.com:119/mozilla.dev.apps.firefox One benefit of discussion in the developer newsgroup is that then everyone will be able to participate, as opposed to only the people cc'd to this (kind of obscure) bug, or only the people who find the (also very obscure) getstatisfaction link. In particular, I would like to hear what functionality people specifically want that isn't be covered by the bugs depending on bug 469426 (details in comment #61). And more importantly, why you want that specific feature. Also, I would like to remind people that wontfixing a very specific bug doesn't at all mean we are refusing to change the interface, it just means that the specific bug didn't accurately describe a set of changes that we are considering (in this case matching every aspect of the functionality in Netscape 4, along with no description in comment #0 to even qualify what that would entail).

(In reply to comment #75) > One benefit of discussion in the developer newsgroup is that then everyone will > be able to participate How a discussion can be started? I'm not familiar with newsgroup. Thanks.

(In reply to comment #76) > How a discussion can be started? I'm not familiar with newsgroup. Thanks. First, set up the news-server (news.mozilla.com) in a news-capable program (I recommend using Thunderbird for participating in newsgroups - and also writing e-mails. ;-) ). Then, "subscribe" to the newsgroup (mozilla.dev.apps.firefox). Then, select the newsgroup and press the "Create a new message" button (just like create a new e-mail). To start a discussion, write your post just like you would write an e-mail. Make sure you give it a good subject name (e.g., "Find Bookmark improvements discussion - from bug 17157"). People will see your post and (hopefully) reply to it. The replies will appear below your post (those are called "discussion threads"). Here's a How-To: http://kb.mozillazine.org/Joining_newsgroups

(In reply to comment #77) > > How a discussion can be started? I'm not familiar with newsgroup. > news-server (news.mozilla.com) ... "subscribe" to the newsgroup (mozilla.dev.apps.firefox) ... "Create a new message" To get it started, I wrote the message. Date 16 Feb 2009 18:26:39, subject "Discussion about several Bookmark/Places improvements required? Inspired by bug 469426".

(In reply to comment #77) > First, set up the news-server (news.mozilla.com) in a news-capable program (I > recommend using Thunderbird for participating in newsgroups - and also writing > e-mails. ;-) ). Then, "subscribe" to the newsgroup (mozilla.dev.apps.firefox). Thanks a lot for the explanation. In the server settings, according to my tests, I guess that I can not use SSL connection and authentication when connecting to this server. Am I right?

(In reply to comment #79) > Thanks a lot for the explanation. In the server settings, according to my > tests, I guess that I can not use SSL connection and authentication when > connecting to this server. Am I right? I don't know. I suggest you ask here: news://news.mozilla.com:119/mozilla.support.thunderbird or here: news://news.mozilla.com:119/mozilla.general ;-)

>To get it started, I wrote the message. Date 16 Feb 2009 18:26:39, subject >"Discussion about several Bookmark/Places improvements required? Inspired by >bug 469426". Thanks Georg, I've followed up in that thread. In addition to using a news reader like Thunderbird, people can also access these threads using the Web or email, more details here: General Information: http://www.mozilla.org/community/developer-forums.html Email list subscription for dev.apps.firefox: https://lists.mozilla.org/listinfo/dev-apps-firefox Google Groups access to dev.apps.firefox: http://groups.google.com/group/mozilla.dev.apps.firefox/topics

(In reply to comment #74) > Are people simply seeing the resolution of this bug and completely failing to > actually read the comments in it? Specifically, please take a look at Comment > 61 and Comment 62 where a number open bugs are linked to for issues that have > been brought up in this bug. Those bugs solve the "Find parent folder" use case. This bug is about searching the bookmarks tree view just like one searches the HTML view. I hope that's specific enough. Why are you not considering this option?

>Those bugs solve the "Find parent folder" use case. This bug is about searching >the bookmarks tree view just like one searches the HTML view. I hope that's >specific enough. Why are you not considering this option? Can you describe the use case that is only served by searching in a tree view, or searching the HTML view. For instance things like selecting a result based on the parent folder, or locating duplicates seem to also be possible with a sortable folder column UI. I'm genuinely curious what problem the tree view search uniquely solves.

The use case is more or less "bookmarks management". Like in other areas, management is partly about having an overview of the managed items. This is quite important for people who have some thousands of bookmarks. (That's also the point of my persisting request to reintroduce separator labels, see https://bugzilla.mozilla.org/show_bug.cgi?id=404983.) Now if you search for bookmarks, a tree view will give you a much better *overview* of the result set than a plain table can do, whatever additional information it may contain or offer to refer to. For example, if you get results in many subfolders distributed widely over your bookmarks tree, you get an immediate feedback that you might need to reorganise your structure somehow. A plain list cannot help you as effectively with organising your bookmarks.

>if you get results in many subfolders distributed widely over your >bookmarks tree, you get an immediate feedback that you might need to reorganise >your structure somehow. So do you think it would be fair to conclude that this feature is primarily useful not specifically for people who have thousands of bookmarks, but rather for people who have thousands of bookmarks that happen to be organized into complex hierarchical structures?

Yes, with the distinction that I wouldn't say they "happen" to be organized ...; They are rather very carefully sorted into a hierarchical structure; that's what the folder paradigm is good for and this feature request is just to consistently support the paradigm in relevant operations.

In comment #83 Alex Faaborg wrote: > Can you describe the use case that is only served by searching in a tree > view...I'm genuinely curious what problem the tree view search uniquely > solves. Yes. I encounter this use case frequently and sometimes resort to loading the bookmark file into an editor just to meet the requirement. Often when I search for a bookmark I don't want to find *just* the matching bookmark, but the ones that are related to it. In my traditional organization structure, that relation is represented by the folder containing the bookmark (and that folder's position in the tree). Each bookmark contained within the folder effectively adds searchable keyword for the topic I'm looking for. I may not remember the name or the spelling of the site I'm looking for, but I'll likely remember a unique word from one of the other sites related to it. Sure, showing search results with a location column addresses this, at the expense of convenience, as I'd need to 1. execute the search, then 2. (ideally) click on the folder name to jump to that folder, or (worse, and what I've been doing with a sporadically functional extension) 3. manually navigate to the shown folder. The vast majority of the searches I perform lead to a desire to view the containing folder. Even in a more typical case where I search for a known site to verify it has been bookmarked, I almost always want to further interact with the containing folder, by either confirming the bookmark is filed correctly, or to add addition related bookmarks. While maybe 80% of my search needs are unmet by the current design, almost none of the searches I perform would benefit from the current design of showing a "search results report." It's superior at finding duplicates, which I rarely do. I don't really follow why the new design was chosen over the Netscape 4.x design. By analogy, consider a word processor with a search feature that let you enter in word fragments, and then it would show you a list of matching words from the document in a report, with no means to navigate to the found words. That's what FF currently implements. It's assumed the only use case for finding a bookmark is to go to that site. If that's all the user wanted, they could do it from the location bar. Searching in the bookmark manager should be optimized for the task of *managing* bookmarks. My interpretation of this bug's summary, "in the same manner as Netscape 4.x" is that you would have some facility to enter in search text, a button to execute the search, and the result would be positioning the bookmark management cursor (highlight) on the first matching bookmark within the bookmark tree (automatically opening folders as required to make the bookmark visible). In addition there would be menu options (or buttons) and key bindings for going to the next or previous match.

(In reply to comment #87) Thanks a lot, Tom, for your very good description of user case. It's close to my use of bookmarks.

(In reply to comment #87) Well done! That precisely describes my (hoped-for) use-case as well. Thanks Tom! REOPEN ? PS. If need be, the Subject of this bug could be renamed to be more specific.

(In reply to comment #89) > REOPEN ? > PS. If need be, the Subject of this bug could be renamed to be more specific. No, as it's been said several times now, specific requests/issues should be filed as new bugs.

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