146165 - find() doesn't search inside a frame when referencing it

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P5)

Description

[Rainer Eschen]

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 :-)

Comment 1

[Bradley Baetz (:bbaetz)]

-> 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.

Comment 2

[Rainer Eschen]

Attachment: Short search engine example to reproduce the bug

Have a look at searchinput.htm, at the end of function forward() and backward()

Comment 3

[Bartosz Wucke]

Linux RC3 i386 - Worksforme. 

Comment 4

[Rainer Eschen]

RC 3 Windows 2000 still doesn't work.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I now get a "permission denied" exception when trying to use find() cross-frame...

Comment 6

[Harshal Pradhan]

Much simpler testcase illustrating exactly what the reporter seems to want to be
able to do. 

http://208.198.42.244/~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?

Comment 7

[Boris Zbarsky [:bzbarsky]]

No idea.  All I was getting was an exception.

This last testcase demos the problem nicely. ;)

ccing some people who may have an idea..

Comment 8

[Harshal Pradhan]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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...

Comment 10

[Hixie (not reading bugmail)]

so what's the verdict? WONTFIX?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Um... More like "someone who knows the find code needs to look at this".

Comment 12

[Akkana Peck]

"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?

Comment 13

[Boris Zbarsky [:bzbarsky]]

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....

Comment 14

[Michael Gorovoy]

This looks like an oldie... However, the Mozilla 1.3a build (Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212) still has this
problem. It is fairly common for a complex web application to use find()
JavaScript method on another frame to hightlight the search results. Is this
ever going to be fixed?

Comment 15

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 16

[Firefox Bug Husbandry Bot]

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.

Comment 17

[Anne (:annevk)]

https://github.com/whatwg/html/issues/3539 will standardize window.find() and we'll follow what comes out of that, but it seems highly unlikely that will allow searching across documents, let alone cross-origin documents.