User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) Build Identifier: When using the embedded browser I cannot get the find in top window to wrap when it reaches the end of the document. I create a com ptr to the nsIWebBrowserFind then set the SetWrapFind to be PR_TRUE .. then call FindNext. It finds the text fine for the first pass, yet when it reaches the end of the document, it does not start over at the begining of the page. Reproducible: Always Steps to Reproduce: 1.using EMBEDDED browser 2.set the wrap find to be true of a nsIWebBrowserFind 3.go to www.cnn.com 4. search for the word "the" 5. search to end of page 6. hit find again Actual Results: selected text remains at the last found entry on the page. Find does not wrap to begining of page Expected Results: Find should have started back at the top of the page. Same results as the first find on the page.
WORKSFORME in mfcembed.
I couldn't get it to wrap around. Charles?
20030214 Trunk: MFCEmbed and Testembed - Verified works for me.
Using 20030227 GRE based mfcembed build, Wrapped finds aren't working. ftp://ftp.mozilla.org/pub/mozilla/nightly/2003-02-27-04-trunk/mfcembed-win32-installer.exe
Confirming new. I have investigated this somewhat and although I haven't gotten to the root cause of it, I think it is due to the way windows differ in embedding and normal Mozilla. Mozilla will usually have a chrome window above the content, whereas embedding has no parent window - the root docshell is the content. I think the find service and particularly, the nsWebBrowserFind::FindNext method is not wrapping back to the root framedocshell properly. There is code after a test against mWrapFind (which is true) after an unsuccesful find that is meant to enumerate docshells, searching one frame at a time for a match. When a page contains an iframe, it looks as though this logic is broken and the code never bothers to search back to the root docshell. It's pretty tricky code to understand, so it might take me some time to work it out. CC'ing Simon in the meantime
I verified this problem with a recent nightly so it still persists in some cases.
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.