Talkback shows this crash as faily common: MyActivateTSMDocument() MyActivateTSMDocument() 0x04612d8c 0x046070bc 0x04606ae0 ns4xPluginInstance::HandleEvent() [/src/chimera/trunk/mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp, line 1182] nsPluginInstanceOwner::ProcessEvent() [/src/chimera/trunk/mozilla/layout/html/base/src/nsObjectFrame.cpp, line 3524] nsPluginInstanceOwner::DispatchFocusToPlugin() [/src/chimera/trunk/mozilla/layout/html/base/src/nsObjectFrame.cpp, line 3178] nsEventListenerManager::HandleEvent() [/src/chimera/trunk/mozilla/content/events/src/nsEventListenerManager.cpp, line 1760] nsGenericElement::HandleDOMEvent() [/src/chimera/trunk/mozilla/content/base/src/nsGenericElement.cpp, line 1688] nsEventStateManager::PreHandleEvent() [/src/chimera/trunk/mozilla/content/events/src/../../../dist/include/xpcom/nsCOMPtr.h, line 631] PresShell::HandleEventInternal() [/src/chimera/trunk/mozilla/layout/html/base/src/../../../../dist/include/xpcom/nsCOMPtr.h, line 643] PresShell::HandleEvent() [/src/chimera/trunk/mozilla/layout/html/base/src/nsPresShell.cpp, line 6150] nsViewManager::HandleEvent() [/src/chimera/trunk/mozilla/view/src/nsViewManager.cpp, line 2037] nsViewManager::DispatchEvent() [/src/chimera/trunk/mozilla/view/src/../../dist/include/xpcom/nsUnitConversion.h, line 90] GlobalWindowImpl::Deactivate() [/src/chimera/trunk/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2330] nsWebBrowser::Deactivate() [/src/chimera/trunk/mozilla/embedding/browser/webBrowser/nsWebBrowser.cpp, line 1647] -[CHBrowserView setActive:]() [/src/chimera/trunk/mozilla/chimera//src/chimera/trunk/mozilla/dist/include/xpcom/nsCOMPtr.h, line 649] _nsNotificationCenterCallBack() _postNotification() _CFNotificationCenterPostLocalNotification() -[NSWindow resignKeyWindow]() endKeyAndMain() -[NSApplication sendEvent:]() -[NSApplication run]() NSApplicationMain() _start() [/SourceCache/Csu/Csu-45//SourceCache/Csu/Csu-45/crt.c, line 267] start()

Just happened to me on a flash site.

Just had this crash with build 2002121904, with macosx10.2.3.

What version of the flash plugin are you using ?

Also, can you provide steps to reproduce?

if another trace is useful, i've got one. i don't know how to reproduce it, but it occured at http://my.yahoo.com/ when Navigator had just lost focus (i was Cmd-TABbing through apps).

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

Is bug 183586 the same issue?

Can't reproduce using Build ID: 2003082702. Steps / other URLs where people experience this?

This is a crash with the Flash plugin.

Works for me

works for me 2003090102 on 10.2.6 [I have a fairly recent flash plug-in).

Doesn't crash, and I think that the Flash plugin is working fine,but I get this ASSERTION failure: ###!!! ASSERTION: OnStopDecode called multiple times.: '!(mState & onStopDecode)', file ../../../../src/modules/libpr0n/src/imgRequest.cpp, line 518 Break: at file ../../../../src/modules/libpr0n/src/imgRequest.cpp, line 518

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

This apparently still occurs with Shockwave Flash 7.0 r24.

This bug has occurred on Safari 2.0 as well. We (the Flash Player team) will investigate a fix.

Any changes here with Flash 8?

Unfortunately, no changes with Flash Player 8, and I'm very sorry. I had seen references to this issue but I didn't have enough information about what was happening until recently, and now it's too late for Flash Player 8. But we have it on our list to investigate in the future.

I think the crash is triggered after flash opened a new window. I got my simple test case here. I think it's related to this bug. 1. Go to http://ktml.net/camino/newwin.html 2. Click on the "click here to open a new window" button (you may have to unblock the popup window) 3. Close the popup window 4. Switch away from Camino to other applications 5. Wait a few seconds 6. Here! One big crash! It works every time for me. Try it!

sorry, forgot to mention: You can download the source code of the newwin.swf at http://ktml.net/camino/newwin.fla What the flash button do is just call the javascript function Launchform() in the newwin.html : <script language="JavaScript" type="text/javascript"> function Launchform() { OpenWin = this.open('blank.html','','scrollbars=yes,menubar=no,height=400,width=500,resizable=no,toolbar=no,location=no,status=no'); } </script>

ktml: nice testcase, thanks! (Note that you have to turn off popup blocking for the site).

Does this still happen with Flash8?

I can't reproduce this with a recent nightly trunk build. Maybe the focus/activate changes from bug 297343 fixed it?

(In reply to comment #23) > I can't reproduce this with a recent nightly trunk build. Maybe the > focus/activate changes from bug 297343 fixed it? It's the #2 topcrasher for 1.0a1 and the current topcrasher for the branch. However, so far there have been no reported crahses since the 5th (when bug 297343 landed), so it seems possible that the changes from bug 297343 fixed it. There was a gap of no crashes between between the previous occurrences, though, so you might want to wait a few more days or for 1.0a2 to be sure before closing this.

Spoke too soon. We're still seeing 1.0a1+ branch crashers for this.

I can reliably reproduce this again now (maybe the fix for bug 311683 "helped"). I debugged by setting breakpoints on NewTSMDocument, ActivateTSMDocument and DeleteTSMDocument, and looking at $r3. Here's the sequence for the steps in comment 19: 1. Load the page with the Flash plugin Flash calls NewTSMDocument (creating TSMDoc A) NSTSMInputContext calls NewTSMDocument (creating TSMDoc B) NSTSMInputContext calls ActivateTSMDocument with TSMDoc B 2. Click the Flash plugin Gecko sets focus on the plugin; Flash calls ActivateTSMDocument(A) (presumably storing current document B) Plugin makes a new window Gecko deactivates the Flash plugin, which calls ActivateTSMDocument(B) 3. New window appears NSTSMInputContext calls NewTSMDocument, creating TSMDoc C NSTSMInputContext calls ActivateTSMDocument(C) NSTSMInputContext calls NewTSMDocument, creating TSMDoc D NSTSMInputContext calls ActivateTSMDocument(D) 4. User closes window. Previous window (containing Flash) is activated. Gecko activates the Flash plugin, which calls ActivateTSMDocument(A) (presumably storing current document D) NSTSMInputContext calls ActivateTSMDocument(B) We hit the event loop, autorelease kicks in. NSTSMInputContext calls DeleteTSMDocument(C) NSTSMInputContext calls DeleteTSMDocument(D) 5. User switches to another app. Gecko deactivates Flash, which calls ActivateTSMDocument(D) <-- BOOM! So the issue here is that Flash is holding on to a pointer to a TSMDocument which belonged to the popup window, and has been deleted.

This patch works around the issue by deactivating the current TSM document every time we close a window (the change is in -windowWillClose:). This should set the active TSM doc to null, which appears to be safe. Flash will then cache 0x00000000 as the active TSM doc when we activate it, rather than the soon-to-be-deleted TSM doc that belongs to NSTSMInputContext.

Comment on attachment 199364 [details] [diff] [review] Workaround patch I don't think Camino's BWC is the right place to handle this. Doesn't it belong in the Cocoa widget library? The patch here will still allow a crash when the evil disappearing context is a tab instead of a window, because -windowWillClose: doesn't get called in that case.

Mark: you're right. Here are some other steps that won't be fixed by that patch: 1. Load http://ktml.net/camino/newwin.html in a tab, and click on the Flash (but not on the text, so don't make a new window). 2. Make a new tab, click in the content area. 3. Click the close box of the new tab. 4. Click on another app. You'll now crash because Flash again cached a pointer to a TSM document that is about to go away.

Here's another way to crash (similar to first): 1. On any Flash applet, context-click, and choose Settings... from the context menu. 2. Close the resulting browser window. 3. Switch to another app.

Here's a testcase to repro the crash entirely within a single web page (with a disappearing iframe).

This patch clears the active TSM document before we focus any plugin. This will prevent Flash from stashing a pointer to a doomed TSM doc. It fixes the crash for me, but needs testing to see if it breaks IME.

Suggested new comment: // Work around an issue in the Flash plugin, which can cache a pointer // to a doomed TSM document (one that belongs to a NSTSMInputContext) // and try to activate it after it has been deleted. See bug 183313.

Comment on attachment 199437 [details] [diff] [review] Patch in nsObjectFrame This covers all of the cases I can cook up, and doesn't seem to do anything evil to text input, although I haven't tested anything "interesting" like Japanese input.

Comment on attachment 199437 [details] [diff] [review] Patch in nsObjectFrame Seeking 1.5rc1 approval. This patch only affects Camino (the NS_FOCUS_EVENT_START -> NS_FOCUS_CONTENT change is a no-op), and is required to fix a top crasher.

Comment on attachment 199437 [details] [diff] [review] Patch in nsObjectFrame sr=pink

Fixed on trunk. Needs approval for 1.8 branch.

Comment on attachment 199437 [details] [diff] [review] Patch in nsObjectFrame approving this camino only change.

Checking in nsObjectFrame.cpp; /cvsroot/mozilla/layout/generic/nsObjectFrame.cpp,v <-- nsObjectFrame.cpp new revision: 1.510.2.4; previous revision: 1.510.2.3