405357 - Firefox crash [@ jpinscp.dll @0xcf45]

Status: RESOLVED FIXED

(Core Graveyard :: Java: OJI, defect, P2)

Description

[Pavel Penaz]

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

Comment 1

[Pavel Penaz]

Attachment: Testcase

This testcase causes Firefox to crash..

Comment 2

[chris hofmann]

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.

Comment 3

[chris hofmann]

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.

Comment 4

[chris hofmann]

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

Comment 5

[chris hofmann]

Attachment: stacktrace reported from brakepad (long)

Comment 6

[chris hofmann]

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)
...
...
...
...

Comment 7

[chris hofmann]

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.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 9

[danielle.pham]

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.

Comment 10

[Damon Sicore (:damons)]

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

Comment 11

[chris hofmann]

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.

Comment 12

[(not currently active) Ted Mielczarek]

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.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

> 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?

Comment 14

[Benjamin Smedberg]

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.

Comment 15

[Masahiro YAMADA]

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

Comment 16

[Steven Michaud [:smichaud] (Retired)]

> 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 17

[timeless]

Attachment: goose meet gander

Comment 18

[(not currently active) Ted Mielczarek]

Comment on attachment 311769 [details] [diff] [review]
goose meet gander

This doesn't fix the crash for me.

Comment 19

[Andrew]

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

Comment 20

[timeless]

[e-mail]: why do you think that the bug would have magically gone away?

Comment 21

[Andrew]

Attachment: saved window proc was not being correctly restored

booleans dont make good window procs.

hopefully bug will magically disappear now :)

Comment 22

[(not currently active) Ted Mielczarek]

That patch fixes the crasher for me.

Comment 23

[timeless]

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.

Comment 24

[Johnny Stenback (:jst)]

(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.

Comment 25

[Johnny Stenback (:jst)]

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

Comment 26

[timeless]

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.

Comment 27

[Andrew]

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.

Comment 28

[timeless]

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...)

[e-mail]: 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.

Comment 29

[Kenneth Russell]

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.

Comment 30

[Johnny Stenback (:jst)]

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?

Comment 32

[Andrew]

Attachment: prevent repeated call to nsObjectFrame::Instantiate

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.

Comment 33

[timeless]

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

Comment 34

[danielle.pham]

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.  

Comment 35

[danielle.pham]

Attachment: DOM elem name collision avoidance test for MojeBanka

Comment 36

[danielle.pham]

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.

Comment 37

[danielle.pham]

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.

Comment 38

[danielle.pham]

Attachment: Testcase to reproduce FF hang problem when LiveConnect is made with reference to an applet's ID.

Comment 39

[Eric Gerds]

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.

Comment 40

[Eric Gerds]

Attachment: FF 3 crashes when applet method is accessed before window.onload fires

Comment 41

[Eric Gerds]

Attachment: FF 3 crashes when non-existent applet property is accessed, before window.onload fires

Comment 42

[Eric Gerds]

Attachment: FF 3 behaves normally when I wait for window.onload to fire.

Comment 43

[Eric Gerds]

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.

Comment 44

[Damon Sicore (:damons)]

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. 

Comment 45

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 46

[Johnny Stenback (:jst)]

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.

Comment 47

[danielle.pham]

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.

Comment 48

[timeless]

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

Comment 49

[Johnny Stenback (:jst)]

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:[e-mail]-plugin-fun/

Comment 50

[Eric Gerds]

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

Comment 51

[Patrick Flaherty]

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

Comment 53

[Mike Beltzner [:beltzner, not reading bugmail]]

Hrm, looks like I was wrong, and this is actually #12 in the topcrash list.

jst: do you think we should block on this?

Comment 55

[Carsten Book [:Tomcat]]

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.

Comment 56

[Johnny Stenback (:jst)]

Fixed by the checkin for bug 430802.

Comment 57

[Johnny Stenback (:jst)]

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!

Comment 58

[danielle.pham]

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.