127589 - control-F does not focus find in this page dialog if it is still active for another tab, and the find dialog does not search the active tab

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Michael Wardle]

When using tabs, I go to tab A, bring up the find dialog (control-F), then go to
tab B, and press control-F to bring up a find dialog on this page.  Nothing
appears to happen.

Trying to search for text shows that the dialog box is still attached to tab A,
rather than tab B as I might have liked.

In preference, there should be a separate find box for each tab, but this was
decided against in bug 127503.  In the absense of this, perhaps pressing
control-F should refocus the find box to the current tab.

Comment 1

[Michael Wardle]

currently using Mozilla 20020204 (0.9.8) Linux version on FreeBSD/x86.

Comment 2

[R.K.Aa.]

To "rehash" the find dialog on successive Ctrl+F (so it "reconnects" to
currently focused window or tab) sounds like a good idea to me. But this is an
RFE, not a bug. Modifying severity.

Comment 3

[R.K.Aa.]

 <timeless> find dialogs should be owned by windows

Comment 4

[jag (Peter Annema)]

There is a bug here. Given two tabs A and B, if I open the find dialog on tab B,
search for something, then switch to tab A, it should either close the find
dialog, or reinitialize the find dialog with the search parameters for tab A. If
you close the dialog, then switching to tab B should probably open it again.

Come to think of it, I can see where you'd even want to share the find context
across tabs, so switching tabs shouldn't reinitialize all parameters, just
reattach to the currently active tab.

cc'ing Simon Fraser, who did the find dialog code (iirc), and Marlon for UE input.

Nominating for nsbeta1 to get a decision on whether this bug is severe enough
that it should be fixed (where the simplest fix probably is closing the dialog
and keeping the current behaviour of one find context per tab).

-> Mozilla 1.0 for now.

Comment 5

[Peter Trudelle]

This isn't just Linux.  Using 2002030703 on Win2K, when I bonk Ctrl-F from tab
B, the Find dialog from Tab A is focussed, but using it will find further
occurrences of the search string in Tab A, which is not even visible.  This is
defective, and we should probably just make Find work in the active tab, either
re-initialized, or retaining separate search strings per tab, whichever is
easier/safer.  Closing the dialog on tab switch seems less desirable, but if it
would be an improvement over current behavior.

Comment 6

[Peter Trudelle]

nsbeta1+/nav3 per Nav triage team, to take the easiest, safest fix possible. 
Not worth much effort.  helpwanted, in case this gets minussed later.

Comment 7

[Peter Trudelle]

whoops, should be nav2

Comment 8

[Syd Logan]

nsbeta1- per ADT

Comment 9

[Peter Trudelle]

Sorry, but Nav triage team decided this was +/2 only 2 days ago.  This is a
major  regression (Find appears broken) in a new feature, and we are fixing it.

Comment 10

[selmer (gone)]

Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!

Comment 11

[Peter Trudelle]

converting nav2->adt2

Comment 12

[Blake Ross]

-> me

Comment 13

[Blake Ross]

Attachment: patch

Comment 14

[Blake Ross]

Attachment: oops: here's the mail patch

Comment 15

[jag (Peter Annema)]

Comment on attachment 80687 [details] [diff] [review]
oops: here's the mail patch

sr=jag

Comment 16

[jag (Peter Annema)]

Comment on attachment 80329 [details] [diff] [review]
patch

sr=jag if you fix the comments about the parameters to findInPage

Comment 17

[Brian Ryner (not reading)]

Comment on attachment 80329 [details] [diff] [review]
patch

r=bryner

Comment 18

[Jaime Rodriguez, Jr.]

let's get this one for RTM, adt1.0.0-.

Comment 19

[Blake Ross]

This patch isn't good. It doesn't deal with focused frames correctly, and I
don't really have any idea how we'll do that, since the frame isn't focused
anymore by the time you hit Find...passing back to jag, maybe he has an idea.

Comment 20

[jag (Peter Annema)]

Andrew, can you see what you can do with this?

Simplest solution might be to back blake's patch out if it was checked in, then
hook up a tab selection listener and close and re-open the find dialog when
someone switches tabs.

Comment 21

[Blake Ross]

(My patch was never checked in anywhere.)

Comment 22

[andreww]

I curious if there are other "dependant" windows that might be effected by 
this like page setup, page info, etc.

Comment 23

[Lori Kaplan]

at the very least the Find window should disappear because users will never
figure out how to make the Find window work in a new tab. the best solution is
to associate the instance of the Find window with the parent tab and display and
hide it as that tab gets focus. 

Comment 24

[Blake Ross]

Well, the best best solution is to just make the find dialog always work...

Comment 25

[Peter Weilbacher]

Has work on this bug stopped? I also find it rather annoying to close and open
the find dialog when switching or closing tabs. The problem is still there in 1.1b.

Comment 26

[R.K.Aa.]

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

Comment 27

[Olav Vitters]

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

Comment 28

[u60234]

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

Comment 29

[u60234]

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

Comment 30

[Samir Gehani]

-> jag

Comment 31

[R.K.Aa.]

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

Comment 32

[Jason Bassford]

Tweaking bug summary so as to decrease filing of dupes (as I did).

FWIW: Find in this Page should behave with tabs the same way it does with
windows.  Personally, I think that the dialogue should remained focused and
usable across everything (tabs and windows) - but, currently, it does disappear
when switching to a different window so, if that doesn't get changed, the same
behaviour should be applied to tabs.

Comment 33

[jag (Peter Annema)]

Attachment: When finding, update web browser find instance if we've switched tabs

When you hit the Find button, see if the window's webBrowserFind has changed
(indicates tab switch), if so, update the cached value in the find dialog, and
it with the new data for the tab.

Comment 34

[jag (Peter Annema)]

Attachment: Fix two bugs in previous patch

Comment 35

[jag (Peter Annema)]

Attachment: Or just use __proto__

Comment 36

[jag (Peter Annema)]

Comment on attachment 120950 [details] [diff] [review]
Or just use __proto__

Nope, that messes with nsFindInstData, not what I want.

Comment 37

[Jan Varga [:janv]]

Comment on attachment 120948 [details] [diff] [review]
Fix two bugs in previous patch

r=varga

Comment 38

[jag (Peter Annema)]

Checked in.

Comment 39

[Robert Ginda]

uh, so I have a question.  Why do I need a global reference to the find data? 
Can't I just pass in a new object every time, it's not like speed is critical here.

For future reference, please observe that in venkman tabs are 4 characters, and
we don't use the g prefix.  Global variables go on the console object, always. 
Also, venkman needs to work on mozilla's as "old" as 1.0, so you need to test if
there is such a thing as "nsFindInstData" before you go ahead an use it.

Comment 40

[sairuh (rarely reading bugmail)]

vrfy'd fixed with 2003.04.23 comm builds, all three platforms. tested with
multiple tabs containing non-framed and framed content.

Comment 41

[Pham]

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