82708 - using Find doesn't alert user when completed searching

Status: VERIFIED DUPLICATE of bug 92102

(Core Graveyard :: Embedding: APIs, defect)

Description

[bmartin]

Latest mfcembed dated: 05-24-01

O/S: Win98
System: Dell Latitude CPi 400Mhz 128MB RAM

Steps:
1. Download and extract latest embed-win32.zip
2. Launch mfcembed.exe
3. Select Ctrl+f to launch the Find dialog
4. Search for the word 'the' and continue until last word is found.

Results:
A dialog should be presented to user once the last word has been found on the 
page.  Dialog should state "Search string not found" or something similar.

Comment 1

[Dave]

See also bug 63410

Comment 2

[Adam Lock]

-> Chak

Comment 3

[Kathleen :Brade]

*** Bug 97862 has been marked as a duplicate of this bug. ***

Comment 4

[Chak Nanga]

->0.9.7

Comment 5

[amutch]

Still not working with MFCEmbed 11/20/2001 Nightly build.  

Comment 6

[Chak Nanga]

Attachment: Patch to an alert if search string's not found

Hi Adam : Can i get an r=?

Can someone else sr= ?

Comment 7

[Chak Nanga]

Hi Adam : Can i get an r=....thanks

Comment 8

[Adam Lock]

r=adamlock

You may wish to consider putting the string into the resource. There is a
version of AfxMessageBox that takes an ID as a parameter.

Comment 9

[Chak Nanga]

Attachment: Updated patch to get the string from the resource file

Per Adam's suggestion....we read the string from the res file now

Comment 10

[rpotts (gone)]

Comment on attachment 58712 [details] [diff] [review]
Updated patch to get the string from the resource file

sr=[e-mail]

Comment 11

[Chak Nanga]

Fix checked in...

Comment 12

[michael wendell]

I am still seeing this problem, but not all the time.  I will be attaching an
html file to this bug.  To see the problem, load the attachment in the browser,
and try to search for the word "local" you will notice that no dialog is
presented when the end of the document is reached.  But if you search for the
word "karzai" a dialog is shown.   

I am reopening this bug.

Comment 13

[michael wendell]

Attachment: Testcase

Testcase referred to in comment #12.

Comment 14

[Chak Nanga]

I was able to reproduce it(both in Netscape 6.2 and in MfcEmbed) using Michael's
attachment given above.

Cc:ing Conrad...

Comment 15

[Conrad Carlen (not reading bugmail)]

Why are bugs like this getting filed against MfcEmbed? I always thought its
point was to show how to use embedding APIs, not be an end-user product. This is
an app useabilty issue, not an embedding issue. It would be an embedding issue
if the Find API put up that alert internally using nsIPromptService -
fortunately it doesn't. I suggest WONTFIX.

Comment 16

[Adam Lock]

Generally I agree and maybe we should be more strict, but if this reproducable
in Mozilla also, it suggests a common cause.

Comment 17

[Chak Nanga]

->0.9.8

Comment 18

[amutch]

These bugs are filed against MFCEmbed because embedders see problems in their
embedded apps that don't appear in Mozilla.  If they can reproduce the problem
in MFCEmbed, it is indicative of a problem in the same core files they use to
build their applications.  Now, in some cases, the functionality might be
outside the range that can be expected from those core files and MFCEmbed.  If
that's the case, let the reporter know and close the bug report. But, there is
functionality, like this one, that should be available to embedders. If you
don't think that's the case, tell us why or let us know what files we should be
including in our builds to provide the functionality.

I doubt all reporters are going to know which bugs fall exactly where.  I know
that I don't. Unfortuantely, in most cases, there is little or no documentation
that tells us what we can and can not expect for embedded apps, especially if we
are not coders.

Comment 19

[Michael Dunn]

If an embedded application encounters a failure and that failure is reproducable
in MFCEmbed then it is a failure worthy of investigation. There may be several
failures only reproducible in an "embedded" context. In that case MFCEmbed
serves as a suitable reference to isolate the failure.

Comment 20

[Adam Lock]

The point in this instance is that this bug IS reproducable in mozilla as well
as embedding. This implies a root cause which is not embedding specific.

The find component doing the searching does reside in mozilla/embedding but it
uses a textservices object from mozilla/editor/txtsvc/ for the grunt work. So
the problem most probably exists in one of these.

Comment 21

[Michael Dunn]

Conrad -- Obviously if repro in MOzilla then that should be noted and the bug
assigned as appropriate (certainly not Chak in this case). Can you set the owner.

Comment 22

[Conrad Carlen (not reading bugmail)]

  Here's what I found with the testcase attachment: The word 'local' exists in
the blue sidebar on the left and in the main body of text. These two are
apparently different frames and we always wrap through multiple frames by
default (bug 92102). On searching for "local" it found one occurence in one
frame, finding the next found nothing (a real bug) and finding the next found
the one in the next frame.
  AFAICT, this is a symptom of bug 92102 which is implemented for both mozilla
and embedding by the same component. Simon - do you want this or should I take it?

Comment 23

[Simon Fraser [no longer active]]

Conrad: you can take this and 92102 if you like. Bug 78305 is also related.

Comment 24

[Conrad Carlen (not reading bugmail)]

Taking bug 92102 and making this a dup since I really think it is.

*** This bug has been marked as a duplicate of 92102 ***

Comment 25

[amutch]

I don't think this was resolved properly.  I don't think this bug is a DUPE of 
92102.  The fix that Chak checked in resolved the reported bug.  The problem 
that was reported on 12/7/2001 was of a different enough nature that it should 
have been filed as a separate bug report or directed to 92102, if that's the 
proper bug for that problem. This bug should have been closed and reported as 
FIXED.  

This may seem like a minor issue but for those of us trying to follow 
particular bugs, it is really confusing to have old bugs marked as a DUPE of a 
more recent bug.  How can #82708 be a DUPE of #92102? Also, if you didn't read 
every entry here, you might think that this issue is still open in Bug 92102. 

I agree that some issue is still open in 92102. However, it is not the problem 
that was reported originally.  Sorry for nitpicking but this isn't the first 
time I've seen this happen.

Comment 26

[michael wendell]

I am verifying this bug.  I am not seeing this problem anymore on trunk build 02-21.