Closed Bug 95748 Opened 23 years ago Closed 16 years ago

Find Bookmarks should select first result instead of opening search-results window

Categories

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

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID
Milestone:
mozilla1.5beta

People

(Reporter: it, Assigned: janv)

References

Details

(Keywords: helpwanted, Whiteboard: [adt2] [UI])

Attachments

(2 files)

Netscape 4.x find results
250.06 KB, image/jpeg
Details
mozilla 1.5 find results
290.52 KB, image/jpeg
Details 
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.
Summary: Bookmark Manager search → Bookmark Manager: Show search results in different window
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp, ui
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
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"
Priority: -- → P5
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?
Severity: minor → enhancement
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
Assignee: pchen → 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".
Summary: Bookmark Manager: Show search results in different window → Find Bookmarks should select first result instead of opening search-results window
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.
Keywords: nsbeta1

*** This bug has been marked as a duplicate of 93058 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
->varga
Assignee: ben → varga
Status: REOPENED → NEW
Priority: P5 → P2
Target Milestone: Future → mozilla1.3alpha
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.
OS: Windows 98 → All
Hardware: PC → All
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)
Target Milestone: mozilla1.3alpha → mozilla1.4beta
*** 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!
QA Contact: claudius → petersen
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?
Whiteboard: [adt2] → [adt2] [UI]
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-
Keywords: nsbeta1+ → 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.
Keywords: helpwanted
> 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.
Target Milestone: mozilla1.4beta → mozilla1.5alpha
> 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 :).
Target Milestone: mozilla1.5alpha → mozilla1.5beta
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.
Flags: blocking1.7+
j - if you want to nominate a bug, you should set the flag to "?". Only Mozilla
drivers are allowed to set the "+" flag.
Flags: blocking1.7+
Note that bug 209201 is related.
Product: Browser → Seamonkey
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.)
Severity: enhancement → normal
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.
Status: NEW → RESOLVED
Closed: 22 years ago → 16 years ago
Resolution: --- → INVALID
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: