Closed Bug 63410 Opened 24 years ago Closed 24 years ago

No feedback when "Find Again" (Ctrl-G) reaches EOF

Categories

(SeaMonkey :: UI Design, enhancement, P3)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: sdm, Assigned: bugzilla)

References

Details

Attachments

(1 file)

1. Go to http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js 2. Ctrl+F to bring up the find dialog. 3. enter "statusbar", hit enter 4. press cancel 5. type Ctrl+G a lot There is no alert saying there are no more matches. An alternative could be to wrap around to the beginning of the page.
i think this is expected behavior [and thus an invalid bug] --Find Again [ctrl+G] will use the last settings you last used in the Find dialog. so, if you hadn't initially selected the "Wrap around" checkbox, hitting ctrl+G numerous times won't wrap around. however, popping up a dialog after searching the end of the document [using Find Again] is a seperate issue --i'll see if it's been filed already [if not, i'll file a new one].
duh. my brain is not on --the summary for this bug would serve fine as an enhancement request. so, to clarify: the first part of this bug [wrapping w/Find Again] is not-a-bug [afaik]. the *second* part of this bug where there's no visual indication of reaching the end of the document using Find Again [nicely summarized already] would be a valid rfe. so, i'm setting as such. assigning to pchen who now owns the Find/Find Again frontend UI stuff. apologies for the earlier noise...
Assignee: ben → pchen
Severity: normal → enhancement
OS: other → All
Hardware: PC → All
clarifying summary a bit. :)
Summary: No feedback when "Find Next" does not find any matches → No feedback when "Find Next" reaches the end of the document
This has been fixed recently (2000-12-06). *** This bug has been marked as a duplicate of 48813 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
not a dup, this deals with find next, which currently only beeps.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Netscape Nav triage team: this is a Netscape beta stopper
Keywords: nsbeta1
Priority: -- → P2
reassigning to mcafee.
Assignee: pchen → mcafee
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.8
Target Milestone: mozilla0.8 → mozilla0.9
Mass moving most of mozilla0.9 bugs to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
resummarizing.
Summary: No feedback when "Find Next" reaches the end of the document → No feedback when "Find Again" (Ctrl-G) reaches EOF
Tree closed for 0.8.1, and since we've been screwing users over with this so far, then can wait another milestone. Moving to 0.9
Target Milestone: mozilla0.8.1 → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
there *is* an audio beep instead of a dialog. Problem is how to get dialog up from C++, find really needs to live in JS land. .91
Keywords: nsbeta1nsbeta1+
Priority: P2 → P3
There's another bug about that, bug 68307, but comments from Bill suggest that the current implementation was done deliberately. Why is getting the dialog up from C++ a problem? We already pose the Find dialog from nsFindComponent, and this is even easier, because it's just a common dialog (well, I suppose we should be using nsIPrompt now -- cc'ing Conrad for info about that).
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from mozilla0.9.1 to mozilla0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** Bug 79643 has been marked as a duplicate of this bug. ***
nav triage team: Pushing out to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
law says we should re-implement find in JS. Over to vishy to find an owner
Assignee: mcafee → vishy
>law says we should re-implement find in JS. Excuuuuuuuuse me, but I did this already. Fixing this is a few lines of JS.
simon would you like to take this, this would be nice to have for rtm.
--> me
Assignee: vishy → blake
Attached patch simple patchSplinter Review
Editor won't get this fix because they're still using the old way. Simon says that probably will change soon. (Wacky 4-space indentation fixed; I should've copied the mode line and the rest of the file instead of the one incorrect line above)
Status: NEW → ASSIGNED
It's a shame that we have to burden browser and mail with an extra string bundle. Maybe we should just move the strings into an existing properties file?
Do mail, view source and navigator have one in common...? I had hesitations too, but it's not really a big deal, since string bundles are lazily instantianted now.
It would also be nice to factor the find dialog's JS to use the same code that puts up the 'not found' alert. Even without that, sr=sfraser
Thanks. (I have a patch for that that I'll put in some other bug.)
awesome. r=alecf
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
vrfy fixed using comm branch bits: linux - 2001.06.25.04 winnt - 2001.06.25.11 mac - 2001.06.25.08
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: