From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 Ctrl+F bookmark searches shows results in different window, whereas Netscape moves a highlight down the list of bookmarks. The latter is more useful as I have groups of bookmarks, but with different keywords, and I often know the name of the first bookmark in the list. Reproducible: Always Steps to Reproduce: 1. Ctrl+B, Ctrl+F 2. 3.

Making summary more descriptive.

Marking NEW.

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.

Mass move Ben's bugs dumped on me marked future with p5 to get off my untriaged radar. You can filter out this email by looking for "ironstomachaussie"

IMHO, the operation you're describing is a "browse bookmarks" sort of thing, which is fine. The bookmark "find" operation, IMHO, looks for multiple bookmarks meeting the criterion entered, and displays them in a new window for manipulation.

hmmm searching bookmarks have evolved several generations since Nav4, it's not going back. However there is an enhancement request floating around somewhwere that should solve yout problem. the request is that typing 'g' for instance would take you to the first bookmark whose name starts with 'g'.

Steven, surely you are right. Search can be search and browse can be browse. However users don't care about the difference. They want to get at their data fast. the old Netscape method is better IMHO. Claudius, if it's evolving in the wrong direction, it should evolve back! Just because there is a new way doesn't mean it's automatically better. The enhancement you mention would be almost worthless for me. I have alot of bookmarks, I didn't realize how many. 2332 lines in my bookmark file. I know these aren't all bookmarks, but still that's a bit of data. They are categoriezed into many 7 main sub-folders with many categories beneath each one. Search with context for finding data essential. grantbow@woody:~ > wc .mozilla/default/9zs8qss8.slt/bookmarks.html 2332 16758 359183 .mozilla/default/9zs8qss8.slt/bookmarks.html

grant, the enhancment I mention would seem to solve the original reporter's problem as I understand it. What are you asking for that isn't solved by the current implementation? The only other useful thing I can think of is that the current search imlplementation should include the title of a bookmark folder in the data that is searched. Would that do the trick?

Hi Claudius, perhaps not only the title of one bookmark folder but something like the "path to the bookmark", meaning the titles of all bookmark folders to the found bookmarks, something like: "Personal Toolbar/subfolder/to/bookmark" and "yet/another/one". I've had the problem sometimes that I don't really remember where I put a bookmark, or if I had this page already bookmarked at all. Then, when performing a search, I did only find that I alread bookmared this page, but not _where_. I needed to search with a text editor in bookmarks.html to find that out. Sure, that's possible but quite uncomfortable... bye, daniel :)

Yes, Daniel said it well. Suppose I don't know if I have something bookmarked or not and I want to group it together with some other ones. I have to first find them all, then move them. The path would assist greatly with this. In-place finding of items is much better since I can directly drag and drop the item to a new location and still understand the other items around it (context) and what other groups may be necessary. Also I can remember what I was thinking by looking at the items in the vicinity of the item I am searching for. "Oh yeah, that was the night I put 5 bookmarks together all about that same topic while searching for something else." I hope this is cogent.

mass reassign of pchen bookmark bugs to ben

I add my voice to Daniel's and Grant comments. I stronly prefer the Netscape 4.x bookmark search function, since it allowed me to find where the bookmarks reside and then move them, reorganizing all my bookmarks, etc... I do not find any new value added with the Netscape 6.x search capabilities.

See also bug 118393, "Find Bookmarks is too heavyweight".

People don't want to search for bookmarks, they only want to *find* them. The 4.x way facilitated finding them, including finding the containing folder and any related bookmarks. Search does not, and I utterly fail at these tasks in NS7. I would consider the current search to be only an unnecessary geeky add-on, if Find weren't oddly missing. This is one of the main reasons I've given up using bookmarks, except for the personal toolbar. I have 1,500 of them, but using NS7 I can find the site I want a lot faster using Google than I can find the bookmark (that I know I have) using search. In 4.x it was the other way around. That ain't right.

*** This bug has been marked as a duplicate of 93058 ***

How ridiculous. Read over 93058 and this bug again so that you can UNDERSTAND how this bug is NOT a duplicate of 93058. Finding bookmarks requires CONTEXT. Just finding a bookmark and then using it is INCOMPLETE. Without CONTEXT (what subfolder the bookmark is located in), using the bookmark manager after having used prior Netscape's bookmark managers for years is just plain annoying.

reopening

Nav triage team: nsbeta1+/adt2

->varga

i think the old netscape method was better. please implement it, in addition to the current method, and add an option to choose one of the two methods. thanks.

I agree. The new method is very slick and very quick to get to many things, but when one has a huge list of bookmarks, or a bad memory, it is very frustrating to find the bookmark but have no way to find which subfolder it is in so that he can move it to a more appropriate subfolder. Also, it is easy to forget all words or wording in the title of a web page. Therefore, this missing feature is a major problem, partly from the new user adoption angle, but very much for us veteran Netscape users.

In addition to Ctrl+F taking me directly to the first result, I would like Ctrl+G to cycle between all possible results (just like in NS4, IIRC). I have close to 4000 bookmarks and have cursed the current search feature at least as often. As others have said, seeing the context of a bookmark is very important. I often feel as if Moz is thumbing its nose at me: "now guess WHERE you filed that". The type-ahead-find idea doesn't even come close to what we already had in NS4. I still want to use the search dialog, I just don't want Mozilla to hand me the results in a bucket. Showing the path to the bookmark isn't as good as jumping right into the folder, IMHO. That being said, I'm not asking for the current search feature to be removed. Maybe it can be called advanced search, but the "in place" search should be the obvious, default one.

I second Alex's comments in #22 - exactly what's needed

A related comment - the Search Results window should be offset from the Bookmarks window. As it is now, the results window is the same size and location as bookmarks and gives the impression it is using same window. This leaves the confusing question of how to clear the results and return to bookmarks. If the new window was offset, down and right is the standard, it would be clear that results are a separate window. Moz 1.1, Windows 2000 (Apologies if this should be a separate bug)

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

Bug 152983 has just been marked as a duplicate of this one, but its messages have some info which I did not see here, so let me add it: The most significant piece of information not mentioned yet for this bug: =============== From Jay O'Brien 2002-07-24 20:31 ------- More comments on this issue: http://obri.net/ns/home.html#020609c - This reference includes this statement among others: in 4.79, I could search for *name*, *location* and *description* ALL AT THE SAME TIME. This is a big time saver in locating bookmarks. In 4.79, I would bring up Bookmarks|Edit, hit ctrl-f and search for something that could be in name, location or description. It was fast and efficient. ================= I personally (and as I know, many others) just can NOT switch to Mozilla - we still use Netscape 4 _only_ for that reason - Bookmarks search: - I (as many others) have *huge* Bookmark.htm - I use Bookmarks at work _all the time_ - I can *not* do my job without Netscape 4's Bookmarks search capabilities - it places me to the needed part of my huge Bookmarks even when I remember _nothing_ about the bookmark I am looking for, BUT remember something about its *neighboring* bookmark - part of its name *or* URL. Please, let us use Mozilla and not Netscape 4.8 :) - make the thing work!

I agree with all people saying that the old 'finding' was more usefull. But why not having both? What about Ctrl+S for 'searching' the bookmark in its context?

Pierre, I remember you already implemented this somehow, not sure if it was complete though. Can you attach your patch ? I don't want to waste time if there is already a patch. However, I can help you finish it up if needed.

yes, I implemented it in js but I accidently lost it when I pulled the bookmark branch. Anyway in order to function correctly, it was dependent on the ds sorting. What are your plans with it, btw?

adt: nsbeta1-

Hi, It's still in the "New" status, not in the "Assigned" :( Please, do something, again, it's the only reason I and many others still use Netscape 4.x and not Mozilla!

Paul, yeah it would be great to have this for 1.4, but as you may have noticed, there is a lot of other bugs. I think it's better to polish things up than adding new features at this point. By the way, you can use quick search bar in the meantime.

> By the way, you can use quick search bar in the meantime. No, I can NOT - this is exactly the point of this *bug* (not a 'new functionality request')! Again, me and others who use Bookmarks _all the time_ (even at work, for work-related things) and who have *huge* Bookmarks files, just can NOT use Mozilla _at all_ with its present Bookmarks functionality. Please spend 3 minutes and see above - Comment #14 by Peter Trudelle - Comment #16 - and mine - #26.

I agree with Paul Gorodyansky on this. There are no workaround and its an important feature missing. And please, change the status of this bug.

> Additional Comment #14: > ... > The 4.x way facilitated finding them, including finding the containing > folder and any related bookmarks. So that those who want finding in context and those who want a list of search results don't accidentally think they're in conflict: Wouldn't it be good to have both forms? Both are useful, even for aspects of the same jobs. To manage bookmarks, you obviously need to be able to find in context (e.g., to rearrange within the containing folder). However, being able to list matching bookmarks could be useful for finding related bookmarks that need to be moved. (Actually, finding in context in a second bookmark tree would be sufficient for that, though a list might still be more convenient.) To find a bookmark whose page to display, being able to list matching bookmarks seems useful. However, being able to find in context is still needed for finding related bookmarks. So, why not re-instate the Netscape 4.x functionality while retaining the form with a list of search results? Perhaps items in the bookmarks search results list could have an action that selects the bookmark in the Bookmark manager window. Hey, is there any central place for noting or discussing bookmark management design issues (as opposed to attaching notes to various bug reports and hoping relevant people find them all)?

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.

Added self to CC. I have begun working on a patch. I'm new to mozilla development, so I don't know how long this will take :).

I liked the idea of adding the function to select a bookmark in the search window and locating that bookmark in the main bookmarks window. I have successfully implemented this when the bookmark is visible in the main bookmarks window, but I cannot get it to work when the bookmark is buried in the tree. I think that I have to search the RDF bookmarks datasource manually and successively find the bookmarks parent folder, and expand that folder, but I have no idea how to traverse the bookmarks RDF datasource. Any help on this would be appreciated.

Ben, I don't think we need that functionality when you 'see Bookmarks as a tree'. All the people who wrote here have _the same_ opinion (please spend 10 minutes and read all the posts here) - it should work as it works in Netscape 4.8: - user does Ctrl/B and comes to the Bookmarks window - there, s/he can search say for "Java" and the search will be done in _three_ objects - Name, Location, Description (with options like "Case Sensitive", etc.) The best way for you is to install Netscape 4.8 and see how it works there.

After reading all the comments (again), it seems to me that people mainly want to be able to find their bookmarks in context of the bookmarks tree. While some people want to might want to do away with the current search altogether, this would require quite a bit of code change. I believe that comment #35 has a reasonable solution that would be a step in the right direction. It should be rather feasible by simply adding a button in the "Search Results" window to locate the selected bookmark in the "Bookmark Manager" window. This would (in theory) open up the tree and display the bookmark in context. This single solution does not address the issue of searching through name, url, and description all at once, but that is actually a separate issue. I am trying to change the code that we have in order to please the two different desires ( 1) see results all at once, and 2) see results in context). I am not interested in scrapping the current code and spending a huge amount of time completely reinstating the Netscape 4 UI/functionality. I don't have that kind of time. Paul, if you are interested in doing this, you, of course, are welcome to try and do this.

Ben, Sorry, I am just a user, so cannot help coding, but we discussed that in so much details - as Jay O'Brien summirized (see the link in comment #26) and Peter Trudelle commented (see comment #33)... Comment #35 that you mentioned does not contradict with the rest of comments at all - yes, we do need it as _separate_ feature that is, if I go to the Bookmarks window (Ctrl/B) I still can have current behavior of collecting the found URLs in one new window, BUT at the same time we want a new button or hot key that would let us find an URL and stop there, be able to do Find Again to stop at the next line, etc. Unfortunately, as it was discussed in this bug's comments and in the comments of another bug that was marked as a duplicate of this one - http://bugzilla.mozilla.org/show_bug.cgi?id=152983, and also in the discussion in netscape.public.mozilla.browser, the following does not answer the real needs of the people: > ... does not address the issue of searching through > name, url, and description all at once, but that is actually a separate issue. Why? Because, IMHO, the code you will write will not give much more than the following steps discussed in the bugs' comments and in the Newsgroup: - I can open a new browser window - do File/Open there and point to my Bookmarks.html - do regular Web-page search using Ctrl/F See? Is it the same as you are going to implement if we cannot search for name, url, and description? I mean, if the link I am looking for has a word "java" only in URL and not in the name, I would never find it, right? :( Anyway, let's see what others write after reading today's comments...

I have learned a bit more about navigating the RDF graphs, so perhaps I can implement this solution: 1. Leave the find dialog unchanged. Add a "Locate in bookmarks" button to the search window. When pressed, this button will transfer focus to the main bookmarks window and open the tree to the requested bookmark and select it. I have already done this. 2. Change the functionality of the search bar in the main bookmarks window. When a user types in a term to search for in the search bar, perform a search for that term in the name, url, description, keywords, etc. Locate the next bookmark that "contains" that term and select that bookmark. If the user pressees ENTER again, the next matching bookmark will be selected. I have not implemented this, but something along these lines is feasible I think. Do these 2 specific actions satisfy everybody? If I have the spare time for this, then I'll do my best. No promises, though - I am still a newbie Mozilla developer, and I have plenty of other things going on right now.

I guess, it would satisfy everybody! But let's wait couple days for people to post their comments... In any case, thanks for your efforts! It would let many people finally use Mozilla in 'production' mode :) - as I use my huge Netscape 4.8's Bookmarks *at work and for work* _every day_. Remember, IE does NOT have Bookmark search and for many people who like me needed that as a must, it was the main reason for not switching to IE!

I agree with Paul!

As an alternative to the button, could you make Ctrl+Enter perform the same "in place" search from the new search bar ? This would make searching easier for keyboard-centric users. I don't think using Enter to cycle through matching bookmarks would be a good idea, as I'd expect the found bookmark to get focus. So pressing Enter would open the bookmark. How about Ctrl+G to cycle ?

Comment #42 (http://bugzilla.mozilla.org/show_bug.cgi?id=95748#c42) from Ben How is a good step in the right direction. But for newbies, it might be confusing. What about adding a checkbox on the search bar titled "Show only results" (default off, but default value configurable in the prefs.js file). If uncheck, search performs as described in sub comment #2 of comment #42, i.e. context lookup. If checked, shows up only the results, like the current behavior.

> 1. Leave the find dialog unchanged. Add a "Locate in bookmarks" button > to the search window. Which search window are you referring to? > When pressed, this button will transfer focus to the main bookmarks window > and open the tree to the requested bookmark and select it. Do you mean that to cycle through all the bookmarks and do something with each one (e.g., edit it), the user has to move back and forth between a search-results list window (to click on the bookmark's line to display it in the bookmark manager window) and the bookmarks manager window? If so, AGH! In NS4, moving to the next match was as easy as pressing Alt-G (ctrl-G?). Please first target parity with NS4's bookmark-management capability, and only then add functionality and/or modify the design.

> Which search window are you referring to? When user presses Ctrl-F...phrase to search...Enter, a new window is displayed that contains the search results. This is the window I'm referring to. > Do you mean that to cycle through all the bookmarks and do something > with each one (e.g., edit it), the user has to move back and forth > between a search-results list window (to click on the bookmark's line > to display it in the bookmark manager window) and the bookmarks manager > window? No. 2 in Comment #42 addresses this. If a user wants to cycle through the results (and not see them in a separate window), pressing enter again (or perhaps Ctrl-G) would go to the next matching bookmark. > Please first target parity with NS4's bookmark-management capability, > and only then add functionality and/or modify the design. Too late :) Functionality (and hence code) has already been changed, and I don't have the time or interest in completely overhauling this part of the code, so if both No. 1 and No. 2 restores most of the Netscape 4 functionality, then that's all I'll do. If the No. 2 fix in Comment #42 does not restore enough Netscape 4 functionality, please explain what you would like changed.

> hmmm searching bookmarks have evolved several generations since Nav4, it's not > going back. The problem is that it has evolved several generations _backwards_ in many areas.: - You can't find bookmarks in context. - You can't search on multiple fields. - You can't finish editing one bookmark and begin editing another with a single click (as Unix versions of NS4 could). - You can't view the bookmarks in sorted order. (Clicking on the column headers now changes the canonical order of the bookmarks; it doesn't just change the order in the view. Who the hell designed that?) PLEASE--first cover NS4 functionality (which has existed for years); _then_ add new functionality.

> 2 in Comment #42 addresses this. If a user wants to cycle through the > results (and not see them in a separate window), pressing enter again (or > perhaps Ctrl-G) would go to the next matching bookmark. But when managing bookmarks, why does the user have to deal with that extra window getting in the way? The usability sucks for the case of managing bookmarks. Finding the next bookmark in the bookmarks hierarchy vs. finding a list of matching bookmarks are DIFFERENT, SEPARATE actions? Why are we trying to cram them together? Why not have TWO search actions, one to find in context and the other to list matches? They could both use the same find dialog, but would be initiated by different keystrokes/buttons/menu items.

> You can't find bookmarks in context. That's what I'm working on. > You can't search on multiple fields. This is partially what will be implemented in No. 2 of Comment #42. This actually does not fall under the summary of this bug. > You can't finish editing one bookmark and begin editing another with > a single click (as Unix versions of NS4 could). This is definitely a separate issue. File a separate bug for that issue. > You can't view the bookmarks in sorted order. (Clicking on the column > headers now changes the canonical order of the bookmarks; it doesn't > just change the order in the view. Who the hell designed that?) I don't know who designated that. That functionality is in Mozilla Firebird, though, so perhaps when the new roadmap takes effect, it will be included. Again, though, this bug does not match this bug's summary. File a separate bug (if one doesn't already exist). > PLEASE--first cover NS4 functionality (which has existed for years); > _then_ add new functionality. It is indeed difficult (if not impossible) to just grab old code, and paste it into Mozilla, so this won't just happen. If you'd like to see Mozilla head in this direction, then we have to work with the code we have and march in that direction. One step at a time. Patience, please.

> But when managing bookmarks, why does the user have to deal with that > extra window getting in the way? The usability sucks for the case of > managing bookmarks. When they use the search bar, they won't have to. It will cycle through the bookmarks. > Finding the next bookmark in the bookmarks hierarchy vs. finding a list > of matching bookmarks are DIFFERENT, SEPARATE actions? Why are we trying > to cram them together? We are not. Finding next bookmark = search bar. Finding a list of matching bookmarks = Ctrl-F/Find dialog. > Why not have TWO search actions, one to find in context and the other to > list matches? This is, in fact, the direction that Comment #42 suggests. It sounds to me like either 1) you didn't read comment #42, or 2) comment #42 wasn't clear enough.

Ben, >> PLEASE--first cover NS4 functionality (which has existed for years); >> _then_ add new functionality. > >It is indeed difficult (if not impossible) to just grab old code, > and paste it into Mozilla, so this won't just happen. Just to clarify the confusion - when several people wrote about Netscape 4 functionality they did NOT mean Netscape 4 *code*. All they mean is _usability_ issues existed in Netscape 4. They did not want you to use Netscape 4 *code*, they suggested you to _look_ on screen how it was done in Netscape 4, that's all! It would help you and all of us A LOT, because it will make new functionality *usable*. Small example - Ctrl/G - if you looked at Netscape 4 screen you would have seen that and people would not write you about it :) As someone here already mentioned, the approach (not code) of Netscape 4 is proven handy and usable by 'generations', so to make new Mozilla Bookmarks search option usable, it would make sense to mimic Netscape 4 behavior (not its code) - why reinvent the wheel and face usability problems? By the way, that search worked in Bookmarks where not all the items were under some folders, many links were just under the root (see in the test example below), especially newly added. It takes 5 minutes to install Netscape 4 :) - ftp://ftp8.netscape.com/pub/communicator/english/4.8/windows/windows95_or_nt/bas e_install/ I even can provide you with _sizable_ Bookmarks file (one for Mozilla - Bookmarks,html and another one for Netscape 4 - Bookmark.htm - where it sits under Users sub-folder) to play with - to search for words used in both Name and URL as well as in Description, for example if there is an item related to the well-known Unofficial Netscape FAQ, it could be found by searching for UFAQ because it's in URL; or check "next Find" (Ctrl-G) by searching for the word UTF... Here it is: http://ourworld.compuserve.com/homepages/PaulGor/book.zip

I too am looking for better 'find' functionality and very much in sympathy with comment #22 and comment #26. I need NS 4.x's find functionality for simple bookmark management and I'd like to see some semblance of it return, i.e. show the found bookmark name/location/keyword in context, i.e. in the tree. see http://bugzilla.mozilla.org/attachment.cgi?id=127368&action=view - not useful is the current http://bugzilla.mozilla.org/attachment.cgi?id=127369&action=view I'd like to summarize as there is a lot of history here (gad almost 2 years!) and I'm not finding the convolution of this conversation at all helpful. Not to mention it's frustrating that nothing has been coded. I see the viewpoints/controversies as being a) usage, and b) presentation/information. As far as usage, we've got two uses of the same bookmark information: 1. bookmark management - i.e. help me restructure my bookmarks 2. information retrieval - i.e. help me get to the web pages Observations: 1. mozilla's current bookmark find function is not at all helpful to #1. Why not? Because it doesn't show a bookmark in context. In addition (I haven't seen this noted anywhere) it doesn't find/list matches on folder names. I'm not really qualified to say if mozilla is particularly good on #2, so I'll withhold comment. 2. Get a better name for the current mozilla function, 'find' 'search', whatever, is an absolute misnomer. I can't think anything in the computer world that equates a simple 'find' with 'find it everwhere and list it', unless the function has an explict mode switch to cause everything to be listed. I can think of some functions that act like this : 'global find', find with a global switch, 'find and list', etc. One such unix function is of course 'grep'. How about we call it grep? <g> 3. There is, or has been, a lot of debate over which format is better. Both formats are useful and needed. Let's get on to defining content of improved function for both formats and get on to coding. As far as presentation: 1. If simple 'first find' ctrl-F can't be done showing tree view then don't bother, it's a must for bookmark management. To show the folder name as a column in a results list doesn't cut it. 2. find, search, etc should be able to home in on both name and location and present same in the results. Same for keyword would be nice, but not a deal breaker. Finally: 1. Seems to me bug #119393 is a dup 2. we commenters should not put the burden on the developers or potential coders or even a reader for that matter to do our homework. If you're going to tell them "I'd like it to look like x", then show them, don't tell them to go off and do something you can/should do.

oops, comment #55 should have read "I think bug #118393 is a duplicate"

This bug has become too broad. I know that most (if not all) of the people watching this bug want exactly Netscape 4's functionality in Mozilla. I don't think that everybody wants it like that, though - some people want to be able to see a full list of results. This is why I don't think it is a good idea to revert everything back. That would just cause a whole new group of people to be unhappy. This bug was opened with the intent of Ctrl+F bookmark search selecting the bookmark in the tree. That's what the summary says. That's what the bug report says. We should focus on that, and on that alone. *IF* that gets done, then we can move on to other issues (like searching name, desc, and URL at the same time). As it appears that I am the only one willing to implement the code necessary, I suggest that we all agree on the requirements of this change before I waste time coding what you guys don't want. Disregard comment #42. Apparently that wasn't a pleasing solution, so I propose a new solution to fix THIS bug. Here it is....drum roll please. 1. Leave Ctrl+F find dialog's UI unchanged (for now). 2. Under Tools menu, change "Search Bookmarks..." to "Find Bookmark...". 3. Under Tools menu, add entry "Find Again" with hotkey Ctrl-G. 4. When user presses "Find" button in Find dialog, the dialog is closed, and a bookmark that matches the query is selected. 5. When user presses Ctrl+G or "Find Again" menu entry, then a different match will be displayed. 6. Leave search bar (in main bookmarks window) functionality unchanged. That is, when a user types a string in the box and presses enter, the main bookmarks tree view will be replaced with the search results in list format. To get bookmarks back, the user must clear the text in the search bar's textbox. If this is not OK, then please tell me specifically which part you would like changed. Don't say "we like Netscape 4 better". I already know that. I am trying to please everybody here -- not just the people watching this bug. I had already seen Netscape 4's bookmark searching in action - I have Netscape 4.75 installed on my machine. I am assuming that it is no different that Netscape 4.8. Someone tell me if I'm wrong. > As someone here already mentioned, the approach (not code) of Netscape 4 is > proven handy and usable by 'generations', so to make new Mozilla Bookmarks > search option usable, it would make sense to mimic Netscape 4 behavior > (not its code) - why reinvent the wheel and face usability problems? The problem is that the bookmarks wheel *has* been reinvented, and I would like to use as much of it as entirely possible rather than throw it away, too. I would like to hear some of Jan Varga's input on this issue. This is a relatively large UI change, and some people higher on the ladder than me (vitually everybody) might object to it. So I do not want to waste time working on implementing the above changes if they will not be included. Please give some reassurance that this won't happen.

Ben, Yes, let's wait for Jan Varga's input and other people inputs, but just small clarification: 1) Yes, Netscape 4.75 is not different from Netscape 4.8 2) > I don't think that everybody wants it like that, though - some people > want to be able to see a full list of results. This is why I don't think > it is a good idea to revert everything back. That would just cause a > whole new group of people to be unhappy. Sure! And it's what the majority of people here wrote - we should not touch or disregard current functionality, we should just _add_ a separate piece of functionality 3) > This bug was opened with the intent of Ctrl+F bookmark search selecting the > bookmark in the tree. That's what the summary says. That's what the bug > report says. We should focus on that, and on that alone. *IF* that gets > done, then we can move on to other issues (like searching name, desc, and > URL at the same time). Here I cannot completely agree - this bug as well as http://bugzilla.mozilla.org/show_bug.cgi?id=152983 - was to make new peice of functionality _useful_ - see Peter Trudelle's comment #14 and similar. Just Ctrl+F - without searching URL - is NOT useful and can easily be done even now by opening Bookmarks.html in a window (agree?) - in both cases Ctrl+F will not find say an item of my Bookmarks if the search word is only in URL and not in Name (which happens VERY often). Just my 2 cents - let's upper-hierachy people decide...

> [many] want...Netscape 4's functionality...[but not] everybody wants it > like that... - some...want...a full list of results. This is why I don't > think it is a good idea to revert everything back. Of course. But hopefully there's a way to provide both types of functionality (maybe just different search commands; maybe in different windows). > [re focusing on just the requested Ctrl-F change and then moving on to > other issues] That sounds find to me. > I suggest that we all agree on the requirements...before...coding... Definitely. > I propose a new solution to fix THIS bug. > ... > 1. Leave Ctrl+F find dialog's UI unchanged (for now). Okay (given the "for now"). > 2. Under Tools menu, change "Search Bookmarks..." to "Find Bookmark...". Sounds fine. > 3. Under Tools menu, add entry "Find Again" with hotkey Ctrl-G. Good. > 4. When user presses "Find" button in Find dialog, the dialog is closed, and > a bookmark that matches the query is selected. Good. The bookmark item selected should probably be either: 1. the first bookmark or folder in the bookmarks hierarchy that matches, or 2. the first one after any currently selected bookmark item. (If multiple items are selected, I don't know if searching should start after the first selected item or after the last seletecd item.) Option 1 forces the user to start at the top, but does match Netscape 4.x's find-in-bookmarks behavior. Option 2, starting after any current selection, lets the user start at any point. Although it doesn't _exactly_ match Netscape 4.x's behavior, the user could clear the selection before finding to start at the beginning and get Netscape 4.x behavior. This open does match the search-from-selection behavior of many editors and the find-in-page function of Netscape 4.x (and Mozilla?). > 5. When user presses Ctrl+G or "Find Again" menu entry, then a different match will be displayed. Good. (Just to reiterate Netscape 4.x's behavior: The next match would not depend on any current selection, but would be based on the previous match. That allows the user to find a match; modify some bookmarks, probably changing the selection; and return to finding subsequent matching bookmarks without having disrupted the search.) > 6. Leave search bar (in main bookmarks window) functionality unchanged. That is, when a user types a string in the box and presses enter, the main bookmarks tree view will be replaced with the search results in list format. To get bookmarks back, the user must clear the text in the search bar's textbox. Okay. Yes, your proposal sounds right to me. > I am trying to please everybody here... Thank you very much. (Seriously.)

> (Just to reiterate Netscape 4.x's behavior: The next match would not > depend on any current selection, but would be based on the previous > match.... I agree. Thank you for the clarification. > The bookmark item selected should probably be either: > 1. the first bookmark or folder in the bookmarks hierarchy that matches, > or > 2. the first one after any currently selected bookmark item. > (If multiple items are selected, I don't know if searching should start > after the first selected item or after the last seletecd item.) I tend to think option 2 is better (for the reasons you mentioned), and yes, Mozilla's find in page function starts looking after current selection (or before if searching backward). I actually forsee some implementation issues with this, but it is definitely a better approach, and we should definitely target it (IMO). Thanks for the clear and specific feeback :) Still waiting for feedback from Jan and others before starting changes...

> Comment #56 F > 2. Get a better name... Do our "Find in page" function and the Find function in many text editors set enough of a precedent to use "find" for finding in context and use "search" for listing things? If not, would the word "locate" work for locating where things are (finding their location)? > ...simple 'first find'...showing tree view...[i]s a must for > bookmark management Definitely. > 2. find, search, etc should be able to home in on both name and > location and present same in the results. Same for keyword would > be nice, but not a deal breaker. I agree. > we commenters should not put the burden on the developers...to do our > homework. If you're going to tell them "I'd like it to look like x", > then show them, don't tell them to go off and do something you can/should do. I was assuming that a good portion of the developers were familar with Netscape 4.x. How wrong was that assumption? (How many paid Netscape/AOL developers are there? Any?)

Much of the confusion in this bug is a result of an unfortunate misuse of the words "find" and "search." The current functionality neither finds nor searches. It does, however, "filter." When the criteria is set, the current functionality allowing those bookmarks that do not match to fall from view, retaining only those that do - much the same way filters are used to separate rocks from soil. When someone sets out to find an item, they are looking for a specific thing. When someone sets out on a search, they usually stop when they come across an item similar to what is desired, however, the search is not necessary ended - that someone is free to continue to search for additions similar items. With the above said, I suggest in the interest of clarity that the current functionality be re-branded as "Bookmark Filter" and the proposed new functionality be branded as "Bookmark Search."

Here's my suggestion for enhancing the bookmark search/find functions. 1.) Current "Search" function: 1a.) Change hotkey for "Tools > Search bookmarks" to something else 1b.) Present search results in a pop-up window instead of main window 1c.) Change search option dialog box title to "Search bookmarks" for consistency with menu 1d.) Add option "Any Field" to select list in dialog box; change "whose..." to "where..." Change 1a. would allow Ctrl+F to be used for "Find" function instead. Change 1b. would prevent the user from getting lost when doing a search since the popup would be opened/closed without disrupting the main window or the current bookmark tree view. Change 1d. would satisfy users who want to search for a match on any field without having to re-work the whole function. 2.) New "Find" functions: 2a.) Add function "Edit > Find bookmark (Ctrl+F)" to find and highlight first occurance in main window bookmark tree view 2b.) Add function "Edit > Find next (Ctrl+G)" to find and highlight next occurance in tree view 2c.) Add function "Edit > Find all" to find and highlight ALL matching occurances in tree view Adding the new "Find" functions to the "Edit" menu instead of the "Tools" menu would keep the Bookmark Manager menu bar consistent with the browser. Functions 2a and 2b would replace the lost NS 4.7 functionality. Function 2c would present the results of the "search" function in the context of the folder structure for easy management. The "Find" functions would use an option dialog similar to the "Search" function. (Note: bug 56418 is almost a dup of this one)

Comments in #64 refer to the Bookmark Manager window. It would also be nice to have an in-context "find" function added to (or in place of) the present sidebar "search" function.

Hi everybody, if i'm allowed i'd like to add my two cents to this long thread. I agree with last comment #64 and #65. When i open the Manage Bookmarks window i'm expecting to be able to manage them. One of the common function, at least for me, is to collect bookmarks spread into different folders and move them in a new one. Or finding duplicates, that when you have nearly 1000 bookmarks are rather common, and deleting them from folders where they don't belong. Now in Manage Bookmarks window there's a wonderful search bar that when used opens a new window with a list of bookmarks, without folder context information, that you can use only by clicking on them to open a tab or browser window. But again if i open a manage window i want to manage them and not perform a quick search to open the bookmark. So far i found a brilliant solution to find bookmarks in their context, open the bookmarks.html in a browser window and Ctrl+F on it :) In a previous comment someone said that introducing context information in the search view may upset a category of users, but while i may agree on that for the quich search performed from the bookmarks tab, where i guess the user want to find a bookmark to click on it, this cannot be true for a search made from a manage window. So i definitely think that search performed from the manage window must show (may be as a selectable option) the results in their folder context. Regards, Gabriele

> ------- Additional Comment #66 From Gabriele Garuglieri 2003-10-02 00:29 ------- > ... > So far i found a brilliant solution to find bookmarks in their context, open > the bookmarks.html in a browser window and Ctrl+F on it :) Lest others not notice the limitations of that workaround, let me point out that that searches only on the bookmark label (not the URL), and you have to manually find the bookmark folder in the management window after finding in in the web page. > In a previous comment someone said that introducing context information in > the search view may upset a category of users... Anyone who thinks that needs to think in terms of use _cases_, not users-- the same user might want both: sometimes wanting a list of matches from which to select one, and sometimes wanting to find bookmarks in place to edit or move them. Speaking of use cases, where are the requirements and design documents for Mozilla?

> ------- Additional Comment #67 From Daniel B. 2003-10-02 07:30 ------- > Lest others not notice the limitations of that workaround, let me point out > that that searches only on the bookmark label (not the URL), and you have to > manually find the bookmark folder in the management window after finding in > in the web page. Well, i know that, and for searching also url i have a more brilliant one, vi the bookmarks.html (sigh!) and search in it :)) Now, without kidding, i have not been able to find a better solution to find bookmarks in their context, do you have one? I like most Mozilla, and it's my browser of choice (apart for those M*ft-ish sites that have pages so tied to those IE specific features(?) that you have to use it or nothing else), and for my everyday use this is the only functionality i really miss, badly miss... Gabriele.

> #68 From Gabriele > ...#67 From Daniel B. > > Lest others not notice ... > Well, i know that, ... Yes, of course. That's why I wrote "others" (those readers _other_ than you). > Now, without kidding, i have not been able to find a better solution to > find bookmarks in their context, do you have one? Netscape 4. That is, I haven't switched to Mozilla at home yet primarily because of the lack of support for managing bookmarks.

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

This seems to be essentially the same problem discussed in bug 56418, which precedes this one and has even more votes. I absolutely agree that the present state of searching bookmarks is abysmal, and that NS4.x was *much* superior. Needed enhancements include search flexibility [upper/lower case, multiselect name/location/description, whole word]. I also prefer cycling through the file from one occurrence to the next. However, even if results still are opened in a separate window, their folder location *must* be indicated. I am perplexed and amazed at the persistence and longevity of these impediments to usability, which also have me sometimes still using NS 4.8! Is this stuff just getting blown off?? IMO, *shortcomings* need to be paid more attention than new bells and whistles! I urge you all to reclassify this is major, if not critical, and look toward getting this tidied up ASAP [preferably for 1.7 final, since that allegedly is targeted to be 'the best Mozilla release ever'. Thanks.

j - if you want to nominate a bug, you should set the flag to "?". Only Mozilla drivers are allowed to set the "+" flag.

Note that bug 209201 is related.

I just now reviewed the comments for this bug, for bug #56418, and for bug #118393. These all appear to be duplicates of each other. Two should be closed. See my comment *67* under bug #56418.

"given this is 4xp it's a bug, not enhancement." (See comment 80 under bug #56418.)

The discussion in this bug has largely moved to what bug 56418 is asking for. However, with 75 comments, this bug is pretty much useless since most of it isn't about the issue in the opening comment. Therefore, I'm going to close this bug as INVALID. You either want bug 56418, or a new one for the original issue if you still feel it is valid.

(In reply to comment #76) > The discussion in this bug has largely moved to what bug 56418 is asking for. > However, with 75 comments, this bug is pretty much useless since most of it > isn't about the issue in the opening comment. Therefore, I'm going to close > this bug as INVALID. You either want bug 56418, or a new one for the original > issue if you still feel it is valid. This is a perfectly valid, albeit cluttered bug. Bug 56418 is about adding a folder column to the filter screen, while this bug is about focusing the search results, like CTRL+F web page search/find works. Please reopen this bug or file a new one that isn't cluttered with "I agree!" comments.