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)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: sdm, Assigned: bugzilla)
References
Details
Attachments
(1 file)
4.03 KB,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•24 years ago
|
||
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].
Comment 2•24 years ago
|
||
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
Comment 3•24 years ago
|
||
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
![]() |
||
Comment 4•24 years ago
|
||
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
Assignee | ||
Comment 5•24 years ago
|
||
not a dup, this deals with find next, which currently only beeps.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 6•24 years ago
|
||
Netscape Nav triage team: this is a Netscape beta stopper
Keywords: nsbeta1
Priority: -- → P2
Comment 7•24 years ago
|
||
reassigning to mcafee.
Assignee: pchen → mcafee
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.8
Updated•24 years ago
|
Target Milestone: mozilla0.8 → mozilla0.9
Mass moving most of mozilla0.9 bugs to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
Comment 9•24 years ago
|
||
resummarizing.
Summary: No feedback when "Find Next" reaches the end of the document → No feedback when "Find Again" (Ctrl-G) reaches EOF
Comment 10•24 years ago
|
||
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
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 11•24 years ago
|
||
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
Updated•24 years ago
|
Assignee | ||
Comment 12•24 years ago
|
||
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).
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
*** Bug 79643 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
nav triage team:
Pushing out to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 16•24 years ago
|
||
law says we should re-implement find in JS.
Over to vishy to find an owner
Assignee: mcafee → vishy
Comment 17•24 years ago
|
||
>law says we should re-implement find in JS.
Excuuuuuuuuse me, but I did this already. Fixing this is a few lines of JS.
Comment 18•24 years ago
|
||
simon would you like to take this, this would be nice to have for rtm.
Assignee | ||
Comment 20•24 years ago
|
||
Assignee | ||
Comment 21•24 years ago
|
||
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
Comment 22•24 years ago
|
||
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?
Assignee | ||
Comment 23•24 years ago
|
||
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.
Comment 24•24 years ago
|
||
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
Assignee | ||
Comment 25•24 years ago
|
||
Thanks.
(I have a patch for that that I'll put in some other bug.)
Comment 26•24 years ago
|
||
awesome.
r=alecf
Comment 27•24 years ago
|
||
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
Assignee | ||
Comment 28•24 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 29•24 years ago
|
||
vrfy fixed using comm branch bits:
linux - 2001.06.25.04
winnt - 2001.06.25.11
mac - 2001.06.25.08
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•