Build: Branch 2001100204 Platform : OS X Expected Results: Qt prefs windows should open. What I got: Application crashes Steps to reproduce: 1) Go to http://ltg.coca-cola.com/ 2) Select Quicktime from menu 3) Click on Play button below US English text. 4) This will cause JS window to appear with embeded QT movie 5) Click on qt movie controller to display popup menu. 6) Select either Plug-in settings or Connection speed. 7) Application should crash
The sample test cause has four different links: 1) link - JS window created with original movie source from page 2) link - Instead of JS window , movie loads in a browser window via target attribute 3) link - JS window created like the first link except it's using a different movie source 4) link JS window created like the first and third link. The difference is it uses HTML to insert the movie. The crash only occurs for me with link 1 and 3. They both insert a raw QT movie (No html) in a JS created window.
This appears to be a Mac OS X issue since I can't reproduce under OS 9.1 or Windows ME.
If feel this is a serious issue since it happens with a popular site. Accessing the QT plugin setting from the QT plugin is pretty common.
Assignee: av → peterlubczynski
Severity: major → normal
Priority: -- → P3
Target Milestone: --- → mozilla0.9.6
I guess it's subjective on how common it is. Users will use it as a shortcut to the QT preference settings. I would like to see this fixed...
Stack trace from crash reporter under Mac OS X 10.1 Date/Time: 2001-10-01 10:51:44 -0700 OS Version: 10.1 (Build 5G64) Command: Netscape 6 PID: 301 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000002d Thread 0: #0 0x02a0c04c in 0x2a0c04c #1 0x00000000 in 0x0 #2 0x02a09fcc in 0x2a09fcc #3 0x0211531c in 0x211531c #4 0x021153a4 in 0x21153a4 #5 0x02115458 in 0x2115458 #6 0x02121880 in 0x2121880 #7 0x021201c8 in 0x21201c8 #8 0x0211f804 in 0x211f804 #9 0x021235c0 in 0x21235c0 #10 0x02125dc0 in 0x2125dc0 #11 0x02125b8c in 0x2125b8c #12 0x021253c4 in 0x21253c4 #13 0x021250a0 in 0x21250a0 #14 0x02124bd8 in 0x2124bd8 #15 0x01e4a208 in 0x1e4a208 #16 0x004ba698 in 0x4ba698 #17 0x004bb038 in 0x4bb038 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 Thread 6: #0 0x70001308 in mach_msg_overwrite_trap #1 0x70006394 in mach_msg #2 0x7017bebc in __CFRunLoopRun #3 0x701b6ba0 in CFRunLoopRunSpecific #4 0x7017b804 in CFRunLoopRunInMode #5 0x7061be08 in XIOAudioDeviceManager::NotificationThread(XIOAudioDeviceManager *) #6 0x706141c0 in CAPThread::Entry(CAPThread *) #7 0x70020efc in _pthread_body Thread 7: #0 0x70043988 in semaphore_timedwait_signal_trap #1 0x70043968 in semaphore_timedwait_signal #2 0x7003fc38 in _pthread_cond_wait #3 0x70623878 in CAGuard::WaitFor(unsigned long long) #4 0x70623954 in CAGuard::WaitUntil(unsigned long long) #5 0x7061a0d4 in XThreadedDevice::IOThread(void) #6 0x7060e484 in XThreadedDevice::IOThreadEntry(void *) #7 0x706141c0 in CAPThread::Entry(CAPThread *) #8 0x70020efc in _pthread_body Thread 8: #0 0x70001308 in mach_msg_overwrite_trap #1 0x70006394 in mach_msg #2 0x700273dc in _pthread_become_available #3 0x700270d4 in pthread_exit #4 0x70020f00 in _pthread_body PPC Thread State: srr0: 0x02a0c04c srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x20000020 lr: 0x02a09fcc ctr: 0x0211c290 mq: 0x00000000 r0: 0x02a09fcc r1: 0xbfffeea0 r2: 0x02662000 r3: 0x00000001 r4: 0xbffff0bc r5: 0xbffff018 r6: 0x00000000 r7: 0x00000001 r8: 0x00000001 r9: 0x00000000 r10: 0x00000151 r11: 0x0001013b r12: 0x0217f53c r13: 0x00000000 r14: 0x00000036 r15: 0xbfffee58 r16: 0xbfffee70 r17: 0x00000001 r18: 0x0066ff48 r19: 0x0000120b r20: 0x00000000 r21: 0x0000001c r22: 0x70004bc4 r23: 0x70004c58 r24: 0x00000001 r25: 0x000006eb r26: 0x8081ab5c r27: 0x0005bbc0 r28: 0x00000000 r29: 0xbfffef00 r30: 0x8081d1cc r31: 0x00000001 **********
The thrid link in the testcase is the only one that crashes for me. Here's a better trace: #0 0x01c80cd4 in ProcessEvent__19pluginInstanceOwnerFRC10nsGUIEvent #1 0x02306808 in 0x2306808 #2 0x01c7c2a4 in HandlePluginEvent__FP10nsGUIEvent #3 0x0228c254 in DispatchEvent__8nsWindowFP10nsGUIEventR13nsEventStatus #4 0x0228c34c in DispatchWindowEvent__8nsWindowFR10nsGUIEvent #5 0x0228c4b0 in DispatchMouseEvent__8nsWindowFR12nsMouseEvent #6 0x022a0cd0 in HandleMouseMoveEvent__17nsMacEventHandlerFR11EventRecord #7 0x0229e9c8 in HandleOSEvent__17nsMacEventHandlerFR11EventRecord #8 0x0229d1bc in HandleOSEvent__11nsMacWindowFR11EventRecord #9 0x022a3eb4 in DispatchOSEvent__16nsMacMessageSinkFR11EventRecordP15OpaqueWin #10 0x022a9024 in DispatchOSEventToRaptor__16nsMacMessagePumpFR11EventRecordP15O #11 0x022a8c28 in DoMouseMove__16nsMacMessagePumpFR11EventRecord #12 0x022a825c in DispatchEvent__16nsMacMessagePumpFiP11EventRecord #13 0x022a7e28 in DoMessagePump__16nsMacMessagePumpFv
Status: NEW → ASSIGNED
Summary: Crash occurs after selecting QT Plugin menu items (Plug-in Settings / Connection speed) → OSX: Crash occurs after selecting QT Plugin menu items (Plug-in Settings / Connection speed)
Target Milestone: mozilla0.9.7 → mozilla1.0
This bug is on the list of Mac bugs identified as significant enough to merit fixing for MachV - adding nsbeta1 keyword. And I can confirm the crash still occurs for me with the 098 build but the stack trace is somewhat different: Thread 0 Crashed: #0 0x0294a2dc in pluginInstanceOwner::ProcessEvent(nsGUIEvent const &) #1 0x020b58a4 in nsBaseWidget::Enumerator::Release( (void)) #2 0x02946e24 in HandlePluginEvent(nsGUIEvent *) #3 0x020ac8c4 in nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) #4 0x020ac99c in nsWindow::DispatchWindowEvent(nsGUIEvent &) #5 0x020acae8 in nsWindow::DispatchMouseEvent(nsMouseEvent &) #6 0x020bdd30 in nsMacEventHandler::HandleMouseMoveEvent(EventRecord &) #7 0x020bc27c in nsMacEventHandler::HandleOSEvent(EventRecord &) #8 0x020bb064 in nsMacWindow::DispatchEvent(void *, int *) #9 0x020c2bc0 in DispatchOSEventToRaptor__16nsMacMessagePumpFR11EventRecordP15O #10 0x020c2858 in nsMacMessagePump::DoMouseMove(EventRecord &) #11 0x020c1a9c in nsMacMessagePump::DispatchEvent(int, EventRecord *) #12 0x020c16d0 in nsMacMessagePump::DoMessagePump(void) #13 0x020c100c in nsAppShell::Run(void) #14 0x02076e4c in nsAppShellService::Run(void) #15 0x004c8bb4 in main1(int, char **, nsISupports *) #16 0x004c968c in main That was with the 3rd link in the testcase.
I can reproduce by clicking on a disabled menu item. Debugger isn't being too friendly, trying printf's
Keywords: nsbeta1 → nsbeta1+
Created attachment 71397 [details] [diff] [review] patch v.1 It looked like the cause of the crash was some erroneous events being passed to us from the widget. This patch takes a more defensive approach to passing events to the plugin by ensure the event was really meant for our plugin's widget. Please review.
so my question is why are we getting bad widgets passed to the plugin code? seems like that's the right fix in addition to making the plugin more robust.
I think the plugin is getting it because it's the "lastWidgetHit" in |nsMacEventHandler::HandleMouseMoveEvent|. The widget in the event isn't the widget that's created for the full-page plugin, but it does look like a valid one in the debugger. Looking in |nsWindow::DispatchWindowEvent|, this->mEventCallback doesn't match mEventCallback of the event's widget either. The plugin-side fix seemed safest to me.
Keywords: patch, review
Not that I'm against additional validation checks, but it seems to me that, if I understand correctly, the plugin code is not really at fault here... fixing the plug-in may leave other crashers lying around. Do I understand correctly, that you suspect |lastWidgetHit| represents the plug-in... even though it is not the most recently "hit" object (which I expect would now be the context menu instead...)? If that's the case, shouldn't |lastWidgetHit| be pointing to the context menu, or the new window, or whatever is now really frontmost, or nothing at all if that's more appropriate? cc'ing saari for some mac event insight...
adding adt1 to status whiteboard as per discussion with beppe.
reduce the urgency on this bug: the scenario is this -- you have to be on OSX, it has to be a js pop-up window with a full-page QT and you must select a disabled menu item on the pop-up. Enabled items do not crash.
Whiteboard: [ADT1] → [ADT3]
Comment on attachment 71397 [details] [diff] [review] patch v.1 I'm sticking by this patch. I think it's the right fix for this bug. It kinda makes sense that the plugin's widget would get the event if it happened in a native widget created by the plugin like the context menu. Where else is the event supposed to go? We have no widget to corespond with the native context menu. Our nearest thing is the plugin's widget which gets the event. I'm willing to leave this bug open or open or open a new one and check-in this band-aid to stop the crash.
Comment on attachment 71397 [details] [diff] [review] patch v.1 >I think it's the right fix for this bug... Ok. r=bnesse
Attachment #71397 - Flags: review+
Comment on attachment 71397 [details] [diff] [review] patch v.1 sr=attinasi
Attachment #71397 - Flags: superreview+
adt1.0.0+ (on ADT's behalf) for approval for checkin. Its good to get the crashers out.
Keywords: adt1.0.0 → adt1.0.0+
Comment on attachment 71397 [details] [diff] [review] patch v.1 a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #71397 - Flags: approval+
Patch in trunk (before branching), marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Keywords: approval → fixed1.0.0
Resolution: --- → FIXED
all tests working ok on 2002040411 trunk on os x, no crash seen. verif.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.