Open Bug 101576 Opened 20 years ago Updated 13 years ago

Find in This Page window remains after all other windows closed

Categories

(SeaMonkey :: UI Design, defect)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

Future

People

(Reporter: mozspam4kurt, Unassigned)

References

Details

(Whiteboard: DUPEME)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010917
BuildID:    2001091712

An open find window will keep mozilla alive after all other windows have been
closed.  Obviously there is no use for "find" once there is nothing to search in.

Similarly, a find window associated with a navigator window will remain once the
navigator window is closed and there is nothing for it to find...

Reproducible: Always
Steps to Reproduce:
1. Open "Find in This Page" window from a browser window
2. Close browser window


Actual Results:  Find window remains

Expected Results:  Find window is destroyed
Status: UNCONFIRMED → NEW
Ever confirmed: true
not a problem on winNT, since closing the last window also closes the Find dialog.

definitely a problem on linux...tried this out on mac os x:

1. with Find open, close all other windows.
2. click Cancel in the Find dialog --the dialog persists.
3. try to select something from the menubar --crash.

->danm? sounds like modal dialog weirdness, but punt/dup as needed.
Assignee: pchen → danm
Depends on: 65521
here's the crash report [2001.10.09.20-trunk for mac os x].


Date/Time:  2001-10-10 17:59:39 -0700
OS Version: 10.1 (Build 5G64)

Command:    Netscape 6
PID:        313

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x000008d4

Thread 0:
 #0   0x000008d4 in 0x8d4
 #1   0x006040d8 in _cl__16nsQueryInterfaceCFRC4nsIDPPv
 #2   0x006042ac in assign_from_helper__13nsCOMPtr_baseFRC15nsCOMPtr_helperRC4nsID
 #3   0x0214be54 in MyMenuEventHandler
 #4   0x73118fe0 in DispatchEventToHandlers
 #5   0x731021bc in SendEventToEventTargetInternal
 #6   0x73150348 in SendEventToEventTargetWithOptions
 #7   0x73139d78 in SendMenuOpening__FP8MenuDatadUlPUc
 #8   0x73153278 in DrawTheMenu__FP14MenuSelectDataPP9__CFArray
 #9   0x731750dc in MenuChanged__FP14MenuSelectData
 #10  0x732d2bac in TrackMenuCommon__FR14MenuSelectDataPUc
 #11  0x73165b58 in MenuSelectCore__FG5PointdUlPP16OpaqueMenuHandlePUs
 #12  0x73188518 in MenuSelect
 #13  0x02131bd4 in 0x2131bd4
 #14  0x021318b8 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord
 #15  0x02131598 in DoMessagePump__16nsMacMessagePumpFv
 #16  0x02130e28 in Run__10nsAppShellFv
 #17  0x01e43464 in Run__17nsAppShellServiceFv
 #18  0x004bae50 in main1__FiPPcP11nsISupports
 #19  0x004bba8c in main

Thread 1:
 #0   0x7000530c in syscall
 #1   0x70557590 in BSD_waitevent
 #2   0x70554a30 in CarbonSelectThreadFunc
 #3   0x70020efc in _pthread_body

Thread 2:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x705594ac in CarbonOperationThreadFunc
 #3   0x70020efc in _pthread_body

Thread 3:
 #0   0x70043988 in semaphore_timedwait_signal_trap
 #1   0x70043968 in semaphore_timedwait_signal
 #2   0x7003fc38 in _pthread_cond_wait
 #3   0x7028366c in TSWaitOnConditionTimedRelative
 #4   0x7027cf10 in TSWaitOnSemaphoreCommon
 #5   0x702c14c8 in TimerThread
 #6   0x70020efc in _pthread_body

Thread 4:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x702505cc in TSWaitOnCondition
 #3   0x7027cef8 in TSWaitOnSemaphoreCommon
 #4   0x7024386c in AsyncFileThread
 #5   0x70020efc in _pthread_body

Thread 5:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x7055b9b4 in CarbonInetOperThreadFunc
 #3   0x70020efc in _pthread_body


PPC Thread State:
  srr0: 0x000008d4 srr1: 0x4000f030                vrsave: 0x00000000
   xer: 0x00000020   lr: 0x006040d8  ctr: 0x000008d4   mq: 0x00000000
    r0: 0x000008d4   r1: 0xbfffec60   r2: 0x039b5001   r3: 0x039b50c0
    r4: 0x0219d9c4   r5: 0xbfffecdc   r6: 0x01cfb2e0   r7: 0x00000003
    r8: 0x00000003   r9: 0x01d00320  r10: 0x000461a0  r11: 0x00000000
   r12: 0x039c05e8  r13: 0x00000000  r14: 0x00000036  r15: 0xbfffee58
   r16: 0xbfffee70  r17: 0x00000001  r18: 0x0005b828  r19: 0x0000170b
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004bc4  r23: 0x70004c58
   r24: 0x00000001  r25: 0x000006eb  r26: 0x8081ab5c  r27: 0x000582a0
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x8081d1cc  r31: 0x00000001

Target Milestone: --- → Future
Using Mac OS 8.6
Build ID 2002012103 keeps spawning defective "Find in Page" dialog boxes.
The boxes have neither "OK" nor "Cancel" buttons.
Hitting Return finds the text, but there's no way to dismiss the box.
Hitting Cmd-F creates a new "Find" dialog.

Cross posting to bug 60618
mass moving open bugs pertaining to find in page/frame to pmac@netscape.com as
qa contact.

to find all bugspam pertaining to this, set your search string to
"AppleSpongeCakeWithCaramelFrosting".
QA Contact: sairuh → pmac
QA Contact: pmac → sairuh
Product: Core → Mozilla Application Suite
Assignee: danm.moz → nobody
I've seen another bug about this symptom but I can't get it back.
Whiteboard: DUPEME
QA Contact: bugzilla → ui-design
You need to log in before you can comment on or make changes to this bug.