Open Bug 101576 Opened 23 years ago Updated 16 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.