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)
Tracking
(Not tracked)
NEW
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
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•23 years ago
|
||
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
URL: http://N/A
Comment 2•23 years ago
|
||
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
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
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
Updated•22 years ago
|
QA Contact: pmac → sairuh
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 5•16 years ago
|
||
I've seen another bug about this symptom but I can't get it back.
Whiteboard: DUPEME
Updated•16 years ago
|
QA Contact: bugzilla → ui-design
You need to log in
before you can comment on or make changes to this bug.
Description
•