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.
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.
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?
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
and moving to m16
*** 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.
verified in 5/8 build.
*** 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")
*** Bug 35711 has been marked as a duplicate of this bug. ***
moving to future milestone
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?
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)
verified in 1/19 build.