User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/2007112505 Firefox/2.0.0.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/2007112505 Firefox/2.0.0.9 Firefox crashes on this page. It seems java is the culprit here, I have Sun Java 6u3 installed. After having checked the crash reports at crash-stats.mozilla.com it seems this is not the only page where Firefox crashes. Please see here: http://crash-stats.mozilla.com/report/list?range_unit=days&query_search=signature&query_type=contains&product=Firefox&platform=windows&version=Firefox%3A3.0b2pre&branch=1.9&signature=jpinscp.dll%400xcf45&range_value=1 Reproducible: Always Steps to Reproduce: 1. visit https://www.mojebanka.cz/CertWizard/?L=CZ Actual Results: Crash Expected Results: No crash

This testcase causes Firefox to crash..

I'm able to reproduce on fx3 windows beta3 Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 but I can't reproduce the test case shown above on Mac trunk builds, firefox 3 beta 3 crash stats have this listed as the 4th ranked crash overall. http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0b3 we should try and get this fixed before firefox 3 ships with a fix in mozilla core code or maybe with a java plugin update.

http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b3&range_value=2&signature=jpinscp.dll%400xcf45 has a list of current blackboxes from beta3.

daniel, can you help find someone to look into this?

talkback shows what looks like the same crash on current 2.0.0.x (12) releases, but the number of crashes for this stack signature is much lower. rank on 2.0.0.12 is around #104. here is an example of a report on fx2.x http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=42137751 Stack Signature jpinscp.dll + 0xcf45 (0x6d4ccf45) 65ff0e28 Product ID Firefox2 Build ID 2007112718 Trigger Time 2008-03-02 13:05:29.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module jpinscp.dll + (0000cf45) URL visited User Comments Since Last Crash 1275 sec Total Uptime 1275 sec Trigger Reason Stack overflow Source File, Line No. N/A Stack Trace jpinscp.dll + 0xcf45 (0x6d4ccf45) USER32.dll + 0x8734 (0x77d48734) USER32.dll + 0x8816 (0x77d48816) USER32.dll + 0xc63f (0x77d4c63f) USER32.dll + 0xe905 (0x77d4e905) PluginWndProc [mozilla/modules/plugin/base/src/nsPluginNativeWindowWin.cpp, line 322] USER32.dll + 0x8734 (0x77d48734) USER32.dll + 0x8816 (0x77d48816) USER32.dll + 0xc63f (0x77d4c63f) USER32.dll + 0xe905 (0x77d4e905) jpinscp.dll + 0x3789 (0x6d4c3789) USER32.dll + 0x8734 (0x77d48734) USER32.dll + 0x8816 (0x77d48816) USER32.dll + 0xc63f (0x77d4c63f) USER32.dll + 0xe905 (0x77d4e905) PluginWndProc [mozilla/modules/plugin/base/src/nsPluginNativeWindowWin.cpp, line 322] USER32.dll + 0x8734 (0x77d48734) ... ... ... ...

cc some additional folks that have poked in plugin code recently to figure out if there is something that can be changed on the mozilla side.

Someone needs to create a Windows debug build (with debug symbols not stripped), run it in gdb, and trigger a crash (perhaps using the testcase from comment #1). After the crash happens, do "thread apply all bt" (in gdb) and attach the results here. It used to be possible to use Cygwin's gdb to do this. I'm not sure it it's still possible with the current build setup ... though if it isn't that's a bug.

I tried with WinXP & Java 6u10 (download from here: https://jdk6.dev.java.net/6uNea.html#Download): (1) For New Java Plugin: https://www.mojebanka.cz/CertWizard/?L=CZ hung on FF3, but run just fine on IE7. (2) For OJI Plugin: both the https://www.mojebanka.cz/CertWizard/?L=CZ and applet detectVM (from Testcase) loaded fine on both FF2 and latest FF3b4pre. There's an NPE thrown when loading https://www.mojebanka.cz/CertWizard/?L=CZ on FF, but it's application related, not Java. I will take a look at the hung problem in (1) right away. But for (2), since OJI plugin from 6u10 works fine, fixing problem in OJI plugin on release older 6u10 will have low priority. If you want to try 6u10, please refer to link above.

If this is really a #6 top crash, let's track this closely. +/P2.

dan or ben, do you have the kind of build set up noted in commment 8, or do you know if that build setup/option still works? I'll try and get something set up, but it might take a couple of days before I can get to it.

Wouldn't using WinDBG + the symbol server have the same effect? http://developer.mozilla.org/en/docs/Using_the_Mozilla_symbol_server http://developer-cluster.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg You should be able to use any Win32 nightly build.

> Wouldn't using WinDBG + the symbol server have the same effect? It's certainly worth a try (though I've never used it and am not familiar with it). The bottom line is that this bug needs an accurate stack trace (one generated from a build with debug symbols) for all threads, hopefully including source-code line numbers (for Mozilla code). > You should be able to use any Win32 nightly build. Are you sure? Does using the the symbol server compensate for the fact that all downloadable distros have their debug symbols stripped?

Yes (on Windows only)... that's the whole point of a symbol server, to download the debugging PDBs the match up with a release binary.

Stacktrace of this bug seems to be same as Bug 275783 Comment #68

> Stacktrace of this bug seems to be same as Bug 275783 Comment #68 Not really -- that stack doesn't have any PluginWndProc. And that crash only happens after you visit another page and come back. But it's still possible that bug 275783 may be related to this one (bug 405357).

Comment on attachment 311769 [details] [diff] [review] goose meet gander This doesn't fix the crash for me.

still present in 3.0pre (BuildID: 2008033105) following link is crash log caused by this issue: http://crash-stats.mozilla.com/report/index/4de2dc4a-ffb3-11dc-895e-001a4bd43e5c

the_bacchus@hotmail.com: why do you think that the bug would have magically gone away?

booleans dont make good window procs. hopefully bug will magically disappear now :)

That patch fixes the crasher for me.

Comment on attachment 314046 [details] [diff] [review] saved window proc was not being correctly restored it isn't a boolean, it's just a bad choice of pointers since afaict it sets up the recursion. I drew a picture for ted, but I'd rather jst explain or review himself. we use mPluginWinProc for GetWindowProc while we want to chain to the plugin. At this point, we want to *stop* chaining to the plugin (and in fact, not have anyone talk to us either), and the way to do that is by undoing to the state from CallSetWindow before we let the plugin window hook itself in. Which is what we store in mPrevWinProc.

(In reply to comment #23) > (From update of attachment 314046 [details] [diff] [review]) > it isn't a boolean, it's just a bad choice of pointers since afaict it sets up > the recursion. > > I drew a picture for ted, but I'd rather jst explain or review himself. I'd love to explain this if I had any real clues about what this actually did. What I do know is that SubclassWindow() returns the previous winproc, and given that, it looks like this code does the right thing unless we're dealing with multiple levels of subclassing, or subclassing multiple windows or what not. Either way though, it does look like this patch also would do the right thing, but I'm wondering if we should only be doing this if mPrevWinProc is non-null rather than if mPluginWinProc is non-null.

Sorry, finger slipped, didn't mean to reassign this to nobody... :(

i was talking to ted later and explained that i didn't like the patch because it bypasses a class as part of the unhook process. for people who want an authoritative explanation as to why, conveniently oldnewthing has one: http://blogs.msdn.com/oldnewthing/archive/2003/11/10/55647.aspx http://blogs.msdn.com/oldnewthing/archive/2003/11/11/55653.aspx In short, you're never supposed to unhook more than your own class. of some interest, UndoSubclassAndAssociateWindow is only called by CallSetWindow which nulls mPrevWinProc not mPluginWinProc. This /kinda/ implies the expected class to be set is indeed the one Andrew picked. the original subclassing is bug 132759 "relatively young as NPAPI code goes" (and relatively old as mozilla code goes) the first round of "fixing" was bug 173206, and its goal was to let the plug-in remove itself from the subclass list (this is "proper" one-at-a-time, however slightly buggy because it doesn't clear the pointer we have). Which indicates that my theory that andrew's pick is wrong is probably also correct. Bug 317486 added the second subclass which is where things got even more complicated Some other scary parts: only UndoSubclassAndAssociateWindow() checks IsWindow, and it still does work on the "window" if the check *fails*. I think the "proper" way to do this (if possible) is: 1. if we are the current window proc 2. if there is a plugin window proc 3. set the plugin window proc 4. clear our pointer to the plugin window proc 5. __try_guard__ 6. SetPluginInstance(nsnull) 7. if we are the current window proc 8. set the previous window proc There are some else cases here at 1 and 7. sadly, they suck. I think the only way we can deal w/ the else cases is to ask windows to destroy the window. to make that work, PluginWndProc needs to handle the destroy window message, and when it does that, it needs to change the window proc to the plugin proc if there is one (nulling pluginproc) and chaining, if plugin proc is null, it needs to set the proc to the prevwindowproc, null that and chain (yes, it can be hit twice). Obviously if we destroy the window, we'll have to replace it, but i'm sure we can do that.

timeless: nice analysis, i was also uncomfortable with skipping the plugin subclassing, and im agreeing with you that the patch is not sufficient. firstly, the crash is occurring because the following steps are taking place: page load: subclass "stack": mPrevWinProc CallSetWindow with a valid instance, subclassing occurs subclass "stack": PluginWndProc,mPluginWinProc,mPrevWinProc then nsAsyncInstantiateEvent is handled: subclass "stack": PluginWndProc,mPluginWinProc,mPrevWinProc CallSetWindow with nullinst, subclassing unhooked, but java does not appear to correctly unhook subclass "stack": mPluginWinProc,mPrevWinProc CallSetWindow with a valid instance BUT WITH THE SAME (HWND)window, java subclasses its own windowproc. subclass "stack": PluginWndProc,mPluginWinProc,mPluginWinProc,mPrevWinProc ie within java itself, mPluginWinProc calls mPluginWinProc, giving stack overflow. I dont have a debug FF2 build, but im assuming the CallSetWindow was never called in this pattern in FF2 (ie unhook then rehook with the same window handle). The correct fix would be to ensure that java unhooks itself. Is this supposed to occur in nsPluginNativeWindow::CallSetWindow(nullinst)? Currently, this will not occur, as SetPluginInstance(nsnull) in UndoSubclassAndAssociateWindow clears nsPluginNativeWindow::mPluginInstance, which prevents mPluginInstance->SetWindow(nsnull) being called in nsPluginNativeWindow::CallSetWindow(). However, even if SetPluginInstance in UndoSubclassAndAssociateWindow is commented out so SetWindow(nsnull) is called on the plugin instance, the GWL_WNDPROC does not change - possibly indicating that java does not unhook in this way? This may be solvable by changes to nsObjectFrame::Instantiate / PrepareInstanceOwner / StopPluginInternal, to prevent tear down and (re)construction of the plugin on the nsAsyncInstantiateEvent, but that would need someone more familiar with the code.

fwiw, our symbol servers include symbols for ff2 releases, so you can skip the build bit and simply grab a release and use them: http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg but do note that comment 0 and comment 6 indicate this does happen there (which doesn't surprise me). fwiw, you can of course view the code online either w/ bonsai: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/plugin/base/src/nsPluginNativeWindowWin.cpp http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/plugin/base/src/nsPluginNativeWindowWin.cpp&rev=FIREFOX_2_0_0_14_RELEASE or mxr: http://mxr-stage.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginNativeWindowWin.cpp http://mxr-stage.mozilla.org/mozilla1.8/source/modules/plugin/base/src/nsPluginNativeWindowWin.cpp (i'm using stage links because mxr-stage lets you change trees w/ a dropdown, this feature will be on mxr fairly soon, but...) kenneth.russell@sun.com: please comment. all we really need to know is: 1. do you ever fix up the windowproc as part of teardown? 2. if so under what conditions if the answer to 1 is no, then: 3. what's the bug number for fixing it and 4. under what conditions would you fix it up (i.e. how should our code help) tomcat: let's start the ball rolling blacklisting java :). andrew: i think i'd rather the code be "correct" for most plugins and if necessary special case the java plugin (see the ->type property). however, i'd sooner blacklist bad versions of the java plugin and make them fix it. we are in a position to tell plugin vendors (and i'm actively doing it) that if they make broken plugins we won't let them into the playground at all. wrt unhook sequence, the only "obligation" I know of is that at destroy window you must unhook yourself and chain (this comes from w32api). there should be some expectations based on npapi but I don't know what they are, at the very least a plugin can't legally leave a hook if we call its NPP_Shutdown method, and one would hope there's some other method with similar obligations. we probably need to test various plugins and document how each one behaves in some database, but that requires an intern. we can agree on private contracts and document them in npapi if we like. if you're actually interested in getting seriously involved in npapi, there's a mailinglist where we could propose such formal contracts. as for more familiar, there really aren't people. the original people involved in the hooking are gone. the person who last touched it is still somewhat around (and cc'd). jst is the owner (victim) of record. and at this point, i think you know more than anyone else :). I think we should try to make the code more correct, so, see if you can get most plugins to survive if we delay clearing mPluginInstance until after the SetWindow call in addition to the other proposed changes. worst case, we can take your wallpaper for the release (imo we shouldn't take it for trunk, i'd rather sun engineers see the problem w/ trunk) and blocklist java.

I'm coming into this discussion in the middle, but at least some of the above analysis was done with the old Java Plug-In and not the new NPRuntime-based one. I can not vouch for the correctness of the old plug-in. Please re-test with Firefox 3 and the latest 6u10 builds from http://jdk6.dev.java.net/6uNea.html . In the new plug-in we do not touch the WNDPROC of the window we receive via SetWindow at all.

Given the complexity of this issue, the ammount of unknowns around this code, and the fact that this is an old crasher that exists in Firefox 2 as well, I'm removing this from the blocker list. This even sounds like something that could and should be fixed in the ("old") Java plugin, and I'd much rather see the plugin fixed than us even attempting to touch this code this late in the game. If we want this fixed for Firefox 3 w/o help from Sun here, I think we need to wait for a dot release and plenty of time to bake this elsewhere. Danielle, any thoughts here? Any chance of getting this issue addressed in the next update for the Java plugin?

The patch is a possible fix for the cause of the window handle being "reused" and therefore incorrectly subclassed. The following stacktrace (captured without the patch) shows the teardown of the plugin subclassing about to occur. nsObjectFrame::Instantiate is being called again (see "->" markers), and this causes reconstruction of the plugin in PrepareInstanceOwner. gkplugin.dll!nsPluginNativeWindowWin::CallSetWindow Line 487 gklayout.dll!DoStopPlugin Line 1779 gklayout.dll!nsObjectFrame::StopPluginInternal Line 1927 gklayout.dll!nsObjectFrame::PrepareInstanceOwner Line 1608 -> gklayout.dll!nsObjectFrame::Instantiate Line 1670 gklayout.dll!nsObjectLoadingContent::Instantiate Line 1693 gklayout.dll!nsAsyncInstantiateEvent::Run Line 149 xpcom_core.dll!nsThread::ProcessNextEvent Line 511 xpcom_core.dll!NS_ProcessPendingEvents_P Line 180 gkwidget.dll!nsBaseAppShell::NativeEventCallback Line 122 gkwidget.dll!nsAppShell::EventWindowProc Line 76 user32.dll!7e418734() user32.dll!7e418816() user32.dll!7e4189cd() user32.dll!7e41ca67() user32.dll!7e4196c7() jpinscp.dll!6d421e41() jpioji.dll!6d44335f() ntdll.dll!7c915b4f() gklayout.dll!nsHTMLPluginObjElementSH::GetJavaPluginJSObject Line 9185 gklayout.dll!nsHTMLPluginObjElementSH::GetPluginJSObject Line 9263 gklayout.dll!nsHTMLPluginObjElementSH::SetupProtoChain Line 8903 gklayout.dll!nsObjectFrame::NotifyContentObjectWrapper Line 1967 gklayout.dll!nsObjectFrame::TryNotifyContentObjectWrapper Line 1711 -> gklayout.dll!nsObjectFrame::Instantiate Line 1693 gklayout.dll!nsObjectLoadingContent::Instantiate Line 1693 gklayout.dll!nsObjectLoadingContent::EnsureInstantiation Line 750 The patch adds recursion prevention when TryNotifyContentObjectWrapper is called, by using the mInstantiating flag. jst/timeless: Please comment if this is a valid thing to do? This patch also appears to correct a side effect of this bug, where a signed java applet could begin execution without its security prompt being accepted (resulting in java.security.AccessControlException) - can not see this issue in bugzilla at this stage.

that sounds very reasonable. please set r?jst :)

Johnny, I think the diagnosis that "the window handle being "reused" and therefore incorrectly subclassed" may be is the consequence of the problem but it may NOT be the root cause to this problem. What I found is: With FF3, if an applet is tagged with an ID that is the SAME NAME as a Javascript function on the page, the result is, the applet gets started twice -- once by the <embed ...> tag that specify the applet, another by the LiveConnect call for the Javascript function of the same name. In the case of MojeBanka, the JS function in turn is to invoke another applet, therefore, the result became very messy. In the MOJE_good.zip, I took the https://www.mojebanka.cz/CertWizard/jsp/applet.jsp and replaced it with the MOJE_applet_good.jsp. The key changes between the 2 files are: 1) Resource references are made local for testing purpose. 2) Line 106, the <embed ...> element is ID changed from "detectVM" to "MYdetectVM" to avoid collision with the detectVM() function on line 123. 3) For simplicity, runNS_EMBED() is replaced to start a simple Clock applet. Now if you run MOJE_applet_good.jsp on FF3, whether with OJI Java Plugin or New Java Plugin, it will run just fine, no crash, no hang, and the MojeBanka's certificate warning will prompt and the suggested config will also show. Now, if you change the <embed> elem ID back to "detectVM", the page will hang with new plugin and crash with OJI plugin. This DOM elem name tag collision is pertained to FF3 only, because MojeBanka site loaded just fine with FF2 and OJI plugin. So please review your patch and make sure it addresses this name tag collision issue. Thanks.

To clarify, the result I saw above is with Windows (XP and Vista). Also, it's best if you could test your change with our latest JRE 1.6.0_10 (6u10). This version of JRE comes with both New Java Plugin (NPRuntime based) and OJI plugin. The default is New Java Plugin. For latest 6u10 download, go to: https://jdk6.dev.java.net/6u10ea.html To toggle between the 2 types of plugin, run Java Control Panel from your Windows' Control Panel. Go to Advanced tab -> Java Plug-in, then click to enable/disable the New Plugin. Restart browser. Since we are working full mode with 6u10, any problem reported on older version will have less attention. Thanks.

Hi all, Here is another manifest of what appears to be similar problem: FF makes excessive calls into Plugin which Plugin does not expect. *** Steps to reproduce: - Run the following applet with FF3 and New Java Plugin from JRE 6u10, FF will hang: http://www.popcap.com/games/free/rocketmania http://www.popcap.com/games/free/atomica I was able to narrow down the problem. Basically, the above games from popcap.com exhibit problem associated with the following pattern in the html/jsp/js file: <script> runApplet(); function runApplet() { document.writeln('<embed ... id="APPLETID" ...>'); // (*) document.getElementById('APPLETID').callJavaMethod()); // (**) } </script> Attached, please find a Clock.zip pkg that contains a much simplified testcase to reproduce the problem seen with popcap.com. The LCHang.jsp in this zip does the above JavaScript pattern. You will find it hang with FF3 & New Java Plugin, but will work with FF3 & OJI (but merely by luck only. OJI will also exhibit becomes choked if the testcase becomes more complicated with LiveConnect calls). With New Java Plugin: For (*), FF3 makes 2 calls NPP_SetWindow() (with valid NPWindow) For (**), FF3 makes 2 rounds of the following 3 calls: - 1 call to NPP_GetValue() for NPPVpluginScriptableNPObject - 2 calls to NPP_SetWindow() (with valid NPWindow) If running using the old OJI Plugin: For (*), FF3 makes 2 calls of NPP_SetWindow() For (**), FF3 make 4 calls of NPP_SetWindow() Overall, whether with New Plugin or OJI plugin, FF does way too many calls to NPP_SetWindow() and NPP_GetValue() that Plugin does not expect. For New Plugin, we anticipate only 1 call to NPP_SetValue() for (*) and only 1 call to NPP_GetValue() for NPPVpluginScriptableNPObject() for (**). For OJI plugin, only 1 call to NPP_SetValue() for (*), and no call to NPP_SetValue() should be needed for (**). Since NPP_SetWindow() will results in plugin preparation for applet startup, excessively calling to this API hampers the applet's lifecycle and result in unpredictable condition in plugin's underlined message queue. While I do understand that this problem may be quite involved to resolve from the browser side, reviewing the script pattern above, it's a very simple LiveConnect scenario that's commonly used by many Java/JS writers in the field. Therefore, I think it is very critical that this problem get addressed the sooner the better. I will check with Ken and other in my group as well to see if there's anyway we can work around this problem from the plugin side. But the chance may be slim. Thanks.

I too have problems with FireFox 3 beta 5 and Java 6 (actually other versions as well). 1) <applet></applet> 2) <script> document.getElementById('appletid').getVersion() </script> 3) FF 3 crashes, FF 2 does not The crash occurs as long as window.onload has not fired yet.

I would like to stress that this error occurs for different Java versions (Java 6, also tested Java 5u1). Firefox 2 does not crash for my test cases. While I don't really understand what needs to be changed with Java, I do strongly believe that FF 3 needs to be fixed somehow - since FF 2 did not crash for these tests.

I'm going to nom this for now. Drivers: Let's leave this on the nom list until JST has had a chance to take a look at this some more.

Blocking- based on comment 30, and the fact that this has slipped to #36 in the topcrash list. If jst sees something that requires blocking, he should renom.

Andrew and/or Danielle, any chance you guys could try out the patch in bug 430802 and see if that fixes this problem as well? It essentially incorporates Andrew's fix (though in a broader sense), and could thus likely fix this problem as well. Thank you Andrew for the analysis and fix here! If the fix for bug 430802 doesn't fix this as well, I'd be ok with taking Andrew's fix here instead.

I'm still having FF3 build error with the new Download Manager and the IAttachmentExecute virus scanner stuffs. If I could resolve this build problem, I'll be glad to check out Andrew's fix. Meanwhile, Andrew, if you have the chance to test your patch, please make sure that it passes with applet loading and applet restarting (browser refresh) and JRE 6u10 for: - http://www.popcap.com/games/free/rocketmania - http://www.popcap.com/games/free/ - mojebanka - LCHang.jsp from Clock.zip attachment - Eric Gerds' testcase Again, for 6u10 download: https://jdk6.dev.java.net/6u10ea.html Thanks a lot.

perhaps we could get a try server build for you to use?

Windows and Mac builds (linux failed due to tree bustage at the time when the try server started the build) with the latest patch for bug 430802 available here: https://build.mozilla.org/tryserver-builds/2008-05-05_16:35-jst@mozilla.com-plugin-fun/

Yes. All of my own test cases behave correctly for that build.

Hi - I'm a programmer, but certainly not a mozilla programmer not have I even done much web programming. So I took the path of least resistance. Use the latest Minefields and, basically, anything java-related has been crashing my browser for at least two wks. E.g. http://crash-stats.mozilla.com/report/index/da35cea1-1b1d-11dd-8cbb-001cc45a2c28 Installed SE 6 U10 Beta (as I think Danielle recommended) and my three test locations all now work without problem: http://www.java.com/en/download/help/testvm.xml http://javatester.org/ http://www.smartmoney.com/eqsnaps/index.cfm?story=earningsForecast&symbol=NOV thanx Danielle (and in the event that your name does indicate you speak French: je vous remercie). pat

Hrm, looks like I was wrong, and this is actually #12 in the topcrash list. jst: do you think we should block on this?

Note: i did tests with jst tryserver build and this build fix the crash (i used the testcase from comment #1) and also the crashes from bug 430699/431178 + Bug 430846 for me.

Fixed by the checkin for bug 430802.

Comment on attachment 316144 [details] [diff] [review] prevent repeated call to nsObjectFrame::Instantiate Clearing review request here, not because it's not a good patch, it was in fact what inspired my work for the bug that fixed this. Thanks again the_bacchus for doing the extensive analysis here!

I also confirm that this fix has corrected all crash/hang that I've seen with mojebanka, popcap's games, and the JS-J Clock applet testcase. Thank you very much.