40583 - "Find in This Page" does not work with frames

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Stephen Ostermiller]

On a page that has frames Find in This page does not find anything.  I can't
tell if it can't find anything (bug 35711) or if it is just taking forever (bug
31770) but in any case it doesn't work.  In Netscape you can click on the frame
in which you want to seach and then find within that frame when you search on
the page.

The java API page is an ideal page to test this, as there is a ton of stuff for
which to search.  If you search for "applet", your browser should find it in any
of the three frames.

Comment 1

[Claudius Gayle]

Find * Search(says so in the component description) moving over to correct component and QA.

Comment 2

[sairuh (rarely reading bugmail)]

simon, d'you see this?

Comment 3

[Simon Fraser [no longer active]]

Hrmm, needs fixing.

Comment 4

[Sean Richardson]

Confirmed with the 2000-05-25-08-M16 nightly binary on WinNT; changing OS to all
There is a beep each time the [Find] button is pressed, but nothing else 
happens. The only way out is to [Cancel].

Comment 5

[sairuh (rarely reading bugmail)]

this is still a problem (eg, try going to http://www.wired.com/ and doing a
search on "the" in the main frame --nuthin' found).

simon, bill, what's the status on this?

Comment 6

[Blake Ross]

Has this ever worked?

Nav4 searches whatever frame is 'activate' upon pressing find.  methinks 
mozilla needs to give clearer designation as to which is the active frame 
(win32 nav4 puts a dark black border around it) but that's a separate bug 
entirely, I guess...

Comment 7

[Simon Fraser [no longer active]]

Yes, it is: bug 42758.

Comment 8

[Jay Patel [:jay]]

Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2. 

Comment 9

[leger]

Per PDT mtg, moving to nsbeta2-.  Not critical to beta2, putting on nsbeta3 
radar.

Comment 10

[Simon Fraser [no longer active]]

Bill: since this is browser, not editor, giving to you. You'll have to mess with 
docShellTrees to get it to do the right thing (and somehow find out which frame 
has focus).

Comment 11

[johng]

nav triage team:
nsbeta3+

Comment 12

[Blake Ross]

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

Comment 13

[Blake Ross]

cc jst from the dup (48530)

Comment 14

[Phil Peterson]

PDT thinks this is a P3 because frames are becoming a lot less common out on the web

Comment 15

[Mike Pinkerton (not reading bugmail)]

frames becoming less common? that's rich. what makes you say that phil? a lot of 
pages are made with frames, just ones w/out scrollbars so you don't know it's a 
frame....

Comment 16

[Johnny Stenback (:jst)]

This is IMO soooo not a P3, P1, no question about it, even if frames would be
getting more uncommon a really, really, really big number of existing pages out
ther on the web uses frames, and I don't see them going away anytime soon. I bet
that a big number of our top100 sites still use frames.

Comment 17

[Stephen Ostermiller]

I can't throw away netscape until this bug is fixed.  It makes it nearly
impossible to browse the java documentation (something I do just about all day
everyday) in a resonable manner using mozilla. (See the URL I associated with
this bug when I submitted it.)

Comment 18

[Simon Fraser [no longer active]]

The fix for this is pretty trivial too, I imagine. I'll see if I can come up with 
a patch.

Comment 19

[Simon Fraser [no longer active]]

I have a fix.

Comment 20

[Simon Fraser [no longer active]]

Fix checked in

Comment 21

[Stephen Ostermiller]

I can verify this bug in the most recent nightly build.  Thanks Simon!

There is one bug that exists with this fix:
You can click in a frame and find something in that frame, but once the find
dialog is brought up you cannot click in another frame to switch the find to the
other frame.  You have to close the find dialog, click on the other frame, and
reopen the find dialog.  I'm not sure if this should be filed as a separate bug,
or if it can be taken care of here.

Comment 22

[Simon Fraser [no longer active]]

Find find window has modality issues, yes. Try bringing up Find on a browser 
window, opening another browser window, and doing a Find there as well. You get 2 
Find dialogs. Please file a separate bug on this.

Comment 23

[Bill Law]

Simon, I'm not sure that's a bug (or at least it ain't that simple).  
Communicator behaves the same way on Windows.  I'm not sure why we'd insist 
there be just one dialog at a time, unless it's some sort of (Mac) religious 
thing.

Comment 24

[Stephen Ostermiller]

I posted find dialog modality issues to bug 52320.

Comment 25

[Blake Ross]

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