Closed Bug 17991 Opened 25 years ago Closed 24 years ago

[Find]Find on page needs visual indication to show when term not found

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sujay, Assigned: bugzilla)

References

Details

using 11/4 build of apprunner(1999110408) on all platforms

1) launch apprunner
2) launch editor
3) type asdf
4) do Edit | Find and enter "donut" as search criteria
5) hit OK on find panel

nothing happens, I don't get an expected error panel "End of document
reached, continue from beginning?" or any other error message.
Status: NEW → ASSIGNED
Summary: problems with Find error handling → Find on page needs indication when term not found
At one point I had code in which beeped when the search term was not found; I
don't know what happened that. I think popping up a dialog is too obtrusive.
Summary: Find on page needs indication when term not found → [BETA]Find on page needs indication when term not found
Whiteboard: [BETA cleanup]
Target Milestone: M14
Isn't there normally a dialog that informs you that the entire file was
searched? Some apps include options to re-search up or down the document.
Setting this to M14 -- should probably be in for beta
What happens on find failure is platform-specific in 4.x. I believe that putting
up a dialog is too obtrusive. Perhaps we should have a status string in teh find
dialog itself?
Whiteboard: [BETA cleanup] → [PRE-BETA]
I agree since you can leave Find open some sort of status/result text withing
the dialog itself sounds like a good idea. Like "No instances of 'foo' found."
remove comment from status whiteboard
Whiteboard: [PRE-BETA]
and moving to m16
Target Milestone: M14 → M16
Summary: [BETA]Find on page needs indication when term not found → Find on page needs indication when term not found
Summary: Find on page needs indication when term not found → [Find]Find on page needs indication when term not found
*** Bug 23945 has been marked as a duplicate of this bug. ***
*** Bug 27817 has been marked as a duplicate of this bug. ***
also affects navigator...
Affects mailnews, too. 
We beep now when the search term is not found.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified in 5/8 build.
Status: RESOLVED → VERIFIED
*** Bug 38809 has been marked as a duplicate of this bug. ***
I'm not sure I agree with this.  I've had my speakers off for the past couple 
of days, and thus the beap is meaningless to me, putting us in the same 
situation as before - there's no indication.  I don't think we can just rely on 
the assumption that all users will have their speakers on; how about some 
visual indication as well?  Simon, what happened to your status text idea?  
That sounded pretty good.  
reopening this for now for some discussion, feel free to close it up if you 
think auditory indication is enough of an indication.

(btw, that's "beep" in my last comment--not "beap")
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: [Find]Find on page needs indication when term not found → [Find]Find on page needs visual indication to show when term not found
Target Milestone: M16 → M20
*** Bug 35711 has been marked as a duplicate of this bug. ***
moving to future milestone
Assignee: sfraser → beppe
Status: REOPENED → NEW
beppe:

I see where we sound the system beep in nsFindComponent.cpp, and where we 
initiate the find via finder.FindNext( data ); in onOK().  Seems to me that if 
we're gonna go along with the status bar idea, we need to be able to check the 
result of finder.FindNext via finddialog.js, so we can interact with the xul-
created statusbar and show the text accordingly.  Is there currently any way to 
get a result from finder.FindNext?  Are there any easy changes such that it 
would return (for example) a boolean value depending on whether any instances 
of the string are found?  

Or am I missing a much, much easier way to do this?
nevermind, sorry 'bout that. I'm an idiot, finder.FindNext will return a value 
(in hindsight, I probably should have checked before asking that...)

Anyways, beppe if you don't mind I'm gonna take this off your plate (for a 
little while, at least) while I work on implementing on that status bar 
idea.  's that ok, or did you have other plans for this?
Assignee: beppe → BlakeR1234
Status: NEW → ASSIGNED
cc'ing beppe (forgot to do that earlier, sorry)

I've implemented a working but simplistic status bar just now, but I was 
wondering how we all thought it should behave.  Something to the effect 
of 'String not found' (or should we specifically name the string?) is probably 
a given when the text isn't found, but how about if it is?  Should it just 
notify the user that it's been found?  Tell how many instances of it were found 
(I don't think the user cares much, though)?  Not say anything at all?

german, or someone - please let me know how you want the status bar to act, and 
what it should display depending on whether or not the search string is found. 
Thanks!
Sorry 'bout all the spam emerging from this bug tonight...last comment:

I just noticed German's old 11/99 comment about possibly having the status bar 
say "No instances of 'foo' found."  This seems okay to me, except we need to 
take into account long strings which obviously won't fit into the statusbar.  
Only solution I can come up with is to do what we've done throughout the app, 
and that is, trim it and add ellipses (...) to make it fit.  We can do this, 
but is it really necessary to spit back at the user what string was or was not 
found?  They know what they're searching for, and it's also right in the 
textfield they typed it in.  Nav4 just yells "Search String Not Found!" to the 
reader, about which I am in agreement with everyone else that it's far too 
"in your face" and intrusive.  Of course, it says nothing if the string is 
found...however, since we're going to have a non-intrusive status bar, we can 
feel free to say that the string is found.  (btw, is 'string' a common enough 
term that non-developers will immediately recognize its meaning?  perhaps we 
should use 'text'?)  In any case, just let me know the strings you feel are 
best and I'll use them.

I was also considering perhaps displaying an icon/changing text color depending 
on whether string is found/not found.  In hindsight, however, this is probably 
a bit much for a simple, plaintext find dialog statusbar.  Again, let me know 
what you want done here.

cc'ing matthew, the ui guy
I don't understand Simon's comment that a dalog would be `too obtrusive'. The 
user is trying to *find* something here. So they're expecting to get *something* 
back, even if it's an error dialog.

Status bar text, even with a beep, would be unacceptably non-obvious. Why did the 
computer beep at me? Was it because Mozilla couldn't find anything? Was it 
because Mozilla ran out of memory when doing the search? Was it because I did 
something wrong? Was it even Mozilla which beeped, and not some other app? If I'm 
looking for the result of a find operation, my eyes are *not* going to be on the 
status bar.

Let's compare with other apps which have Find functions...
* Word 98: a dialog. `Word has finished searching the document. The search item
  was not found.'
* Excel 98: a dialog. `Microsoft Excel cannot find the data you're searching for.
  If you are certain the data exists in the current sheet, check what you typed
  and try again.'
* PowerPoint 98: a dialog. `PowerPoint has finished searching the presentation.
  The search item was not found.'
* BBEdit: just beeps. (But on Mac OS, if you have the volume turned down to
  zero, `beep' is interpreted as `flash the menu bar'. XPToolkit doesn't allow
  for such niceties, yet.)
* SimpleText: just beeps. (Ditto.)
* Sherlock 2: a dialog. `No items were found.'
* ClarisWorks 5.0: a dialog. `The text "donut" could not be found.'
* Claris Home Page 2.0: a dialog. `The string "donut" could not be found.'

I think that's pretty conclusive ...

The only objection you could have to a dialog is that it acts as an annoyance if 
you want to revise your search -- you have to do an extra key press before you 
can get back to the Find dialog. But this problem can be removed if a `Find
Other ...' button is added to the error dialog, and made the default action. Then 
Cancel (Escape) would have the intuitive role of backing out of find mode 
altogether.

Like this:
+-------------------------------------------+
| Search Results :::::::::::::::::::::::::::|
+-------------------------------------------+
| /.\ The text "donut" was not found in the |
| \1/ document.                             |

Bottom of dialog (Mac OS, Unix):
|                                           |
|           ( Cancel )(( _Find Other ... )) |
+-------------------------------------------+

Bottom of dialog (Windows):
|                                           |
|     (( _Find Other ... )) ( Cancel )      |
+-------------------------------------------+

I don't understand the difference between "Find Other..." and "Cancel" (not 
that I think a "cancel" button belongs on this type of dialog, anyways).  
Closing the alert via any means would still bring you back to the Find 
dialog...so what would be the difference in function between "Find Other..." 
and "Cancel" ?
No, you can get "string not found" by pressing Ctrl-G when the find dialog is 
not open.  This proposal (if I understand it) would have "Find other..." 
(re)open the find dialog while "Cancel" would just dismiss the "string not 
found" dialog.
* `Cancel' would cancel you out of `finding stuff' mode. It would close the error
  dialog and return you to the document.
* `Find Other ...' would close the error dialog, and reopen the Find dialog to
  allow you to find something else. (The contents of the Find dialog would, of
  course, be pre-set to whatever you searched for last time.)

Even if you selected `Find Other ...' by mistake, and the Find dialog reopened, 
you could still exit out of `finding stuff' mode by selecting `Cancel' (or 
pressing Escape) in the Find dialog itself.

ah, I understand.

Can we get some feedback from those who thought a dialog was too obtrusive?
I would appreciate if someone could give me some direction here, since I can't 
make the decisions.  Status bar?  Dialog?  Just a beep?  Please let me 
know...I'm willing to do whatever work is required, but I can't until I'm told 
what to do.
my recommendation would be to provide an error dialog that states the document 
has been searched and the string could not be found. I would think an OK would 
be the logical button on the dailog. The search dialog would still be present 
and the string in question should be selected so the user could immediately type 
in a new string, or simply cancel.
I would like to see a text message in the status bar or in the search dialog
itself.  Why open another dialog?
You need to open another dialog because, as already discussed, status bar text is 
not obvious enough -- and because the original Find dialog should have closed as 
soon as you clicked Find. And the original Find dialog should have closed as soon 
as you clicked Find (4xp, but not happening in Seamonkey at the moment) because 
otherwise it's very likely to obstruct the text it's found.

I like the fact that the search dialog stays open.  This allows me to continue
the search by clicking the mouse button.  The mouse pointer should be close to
the dialog if you use the mouse to click the "Find" button so you shouldn't have
to move the mouse to click find again.  This also has the benefit that I can
change the search parameters (search string, forwards, backwards, etc.) without
having to re-open the dialog.

Ideally, when you first clicked `Find', it would collapse to a toolbar -- so you 
could choose `Find Next', `Find Previous', etc with the mouse, and it still 
wouldn't get in the way of the found text. But that's an RFE for another day; and 
4xp (on Mac, at least) is to close the dialog when you first click `Find'.

*** Bug 57286 has been marked as a duplicate of this bug. ***
*** Bug 54249 has been marked as a duplicate of this bug. ***
*** Bug 62027 has been marked as a duplicate of this bug. ***
ok, bug 48813 is specifically for the "Search String Not Found!" dialog, I have
a fix. I'm going to check it in once I get reviews... it's better than just
beeping, which is what it does now
Alec has checked in the alert, and we never reached a consensus here about 
alternative means of notifying the user.  closing this out, file new bugs for 
specific, detailed changes to make (e.g. matthew's toolbar idea)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
verified in 1/19 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.