From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) BuildID: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 I use find() to search inside frames for strings. The old Netscape 4.7 works fine, but Mozilla searches inside the calling frame not the one I reference. Example Frameset (search.htm): <FRAMESET FRAMEBORDER="0" ROWS="150,*" FRAMESPACING="0" BORDER="0"> <FRAME SRC="searchload.htm" NAME="searchinput" SCROLLING="NO" NORESIZE="NORESIZE" FRAMEBORDER="0"> <FRAME SRC="searchhelp.htm" NAME="searchoutput" NORESIZE="NORESIZE" FRAMEBORDER="0"> </FRAMESET> Function call in searchinput frame (searchinput.htm): parent.searchoutput.find("Text",false,false) The find should search inside the searchoutput frame but it searches in the searchinput frame. So the reference to the window object is ignored. Reproducible: Always Steps to Reproduce: Use "begin" as search term in the url example I've created for you and click on the sunglasses. If you use the find next button under the "tip" text it shows the wrong result. You may try the Netscape 4.7 or the MSIE 5.5 to see what is the correct behavior. Actual Results: The "Begin of word" in the searchinput frame is highlighted... Expected Results: ...instead of the first "begin" of the hitlist in the searchoutput frame. Meanwhile the find() works (I waited for this some time). If you fix the frame reference problem Mozilla can be used by my customers for client-side search engines with highlighting inside the found pages :-)
-> DOM mozilla extentions I can't see a call to find() in that page - can you make a small, selfcontained test, and attach it to the bug? not a blocker.
Assignee: rogerl → jst
Severity: blocker → major
QA Contact: pschwartau → lchiang
Created attachment 84698 [details] Short search engine example to reproduce the bug Have a look at searchinput.htm, at the end of function forward() and backward()
Linux RC3 i386 - Worksforme.
RC 3 Windows 2000 still doesn't work.
Attachment #84698 - Attachment mime type: application/octet-stream → application/zip
I now get a "permission denied" exception when trying to use find() cross-frame...
Much simpler testcase illustrating exactly what the reporter seems to want to be able to do. http://22.214.171.124/~hpradhan/testcases/146165/index.html * Mozilla 1.2b and trunk on Win2K seem to do the wrong the thing. * Mozilla 1.0 on solaris also does the wrong thing. (no newer unix copy here) * My creaky old copy of NS4.7 on solaris looks like its doing what the reporter expected. Based on that, confirming. Boris: No permission execptions here. What exactly were you seeing?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
No idea. All I was getting was an exception. This last testcase demos the problem nicely. ;) ccing some people who may have an idea..
Well it seems the problem arises from what docshell does in nsDocShell::EnsureFind() does here http://lxr.mozilla.org/mozilla/source/docshell/base/nsDocShell.cpp#6583 Notice that we will always end up looking in the "focussed window" which in this case happens to be the wrong one.
So the problem is that calling window.find() in a frame should find in all frames. But calling foo.find() from a different frame should not. Is that the issue here? If so, I dont really see a way to reconcile those...
so what's the verdict? WONTFIX?
Um... More like "someone who knows the find code needs to look at this".
"Someone who understands the find code needs to look at this" meaning the find code in nsDocShell.cpp, and specifically what the find() dom call is intended to do, I presume. Is jst that person?
That's what I meant, yes... I don't know who the right person is; otherwise I would have reassigned it... jst's not really reading bugmail, though, so if he's the right person someone should mail him....
Mass-reassigning bugs to firstname.lastname@example.org
Assignee: jst → dom_bugs
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.