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

NEW
Unassigned

Status

()

P5
major
17 years ago
4 months ago

People

(Reporter: eschen, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---
Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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
Component: JavaScript Engine → DOM Mozilla Extensions
QA Contact: pschwartau → lchiang
(Reporter)

Comment 2

17 years ago
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()

Comment 3

17 years ago
Linux RC3 i386 - Worksforme. 
(Reporter)

Comment 4

17 years ago
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...

Comment 6

16 years ago
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?
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..
Keywords: testcase

Comment 8

16 years ago
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...

Updated

16 years ago
QA Contact: lchiang → ian
so what's the verdict? WONTFIX?
Um... More like "someone who knows the find code needs to look at this".

Comment 12

16 years ago
"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....

Updated

16 years ago
Flags: blocking1.3-

Comment 14

16 years ago
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?
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Assignee: general → nobody
QA Contact: ian → general
(Assignee)

Updated

6 years ago
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.