crash in jpinscp.dll (JavaScript calling an applet causes NS_ERROR_FAILURE)




11 years ago
10 years ago


(Reporter: mozilla, Unassigned)



Windows XP
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)





11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/20080311 Firefox/
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

If I use FF3 to call from JavaScript into an applet I see this error:

[Exception... "Failure" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: ::  :: line 5" data: no] 

This doesn't happen with FF2.  I've isolated a simple reproducible test case in test.html.

Reproducible: Always

Steps to Reproduce:
1. Visit
2. See the exception caught and written into the page.

Comment 1

11 years ago
Wow - just tried your test page under Windows XP and my results were even worse. In my case it CRASHED Firefox hard.

As soon as I entered the URL and hit return, Firefox crashed and displayed a message saying so, and asking if it could automatically report the bug, which I allowed it to do.  I tried this both with FF 3 beta 3 and FF 3 beta 5, both with the same exact result.

This is definitely a show stopper IMHO until its is resolved.  It will definitely cause MAJOR problems for our sites and I'm sure many others that use JavaScript to Java communication.

Thanks in advance for looking into this!

Comment 2

11 years ago
Updating Hardware, OS, and Severity based on Ron's comment.

I don't know if it's truly All but it's at least Mac + Windows.
Severity: major → critical
OS: Mac OS X → All
Hardware: Macintosh → All

Comment 3

10 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008042904 Minefield/3.0pre

Works For Me with this build
Steps to Reproduce:

1. Visit
Result: I get a white page
with 1 line:

Apple inc.

perhaps it is INTEL?


Comment 4

10 years ago
My original report was on PPC actually.  "Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5".  I simply filed the bug from my laptop which is Intel.  I do notice you have a month later build than mine.

Comment 5

10 years ago
A few days ago I tried with the nightly build under Windows and it is still crashing. Sounds like progress has been made on the Mac front, so that is good. But certainly Windows remains a critical issue as we cannot have browsers crashing just by visiting a page. As mentioned previously this does not happen with any FF 2.x build, only in the 3.x branch. Please advise. Thank you!


10 years ago
Flags: blocking-firefox3?
--> Core::JS
Assignee: nobody → general
Component: General → JavaScript Engine
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general
Carrying over blocking nomination, cc'ing some likely suspects.
Flags: blocking1.9?
Do we have crash reporter URLs or a regression window for this?
Ever confirmed: true
FWIW, I can confirm the crash on Windows only, and only if the user has a JVM installed. The crash takes down Firefox without it sending a crash report.

Here's something interesting, though - sometimes if I start a new session or clear private data, I see:

	at sun.plugin.AppletViewer.loadJarFiles(Unknown Source)
	at sun.applet.AppletPanel.runLoader(Unknown Source)
	at Source)
	at Source)

in the JVM error console and:

Sun Microsystems Inc. 

in the content area of the page.

Not sure what would cause that.
OS: All → Windows XP
Hardware: All → PC
It seems to be related, FWIW, to whether or not there are JVM icons left dangling in my system tray - that makes me believe that the crash is that the JVM not shutting down properly after catching the null pointer exception, and trying to start up a new JVM instance leading to a crash in Firefox.

Do we have an example of JS calling a servlet without a null pointer exception?
I get the crash on Vista, in jpinscp.dll, which is a DLL of Sun's Java VM. I have jre1.6.0.02.
i will search for the regression range.
Version: unspecified → Trunk
tomcat: please renom if you get a regression range; thx!
Flags: blocking1.9? → blocking1.9-
Summary: JavaScript calling an applet causes NS_ERROR_FAILURE → crash in jpinscp.dll (JavaScript calling an applet causes NS_ERROR_FAILURE)
(In reply to comment #13)
> tomcat: please renom if you get a regression range; thx!

Why is a blocker nomination approval dependent on finding a regression range? It would seem to depend on severity only, from first principles.

(In reply to comment #8)
> Do we have crash reporter URLs or a regression window for this?

Crashreport is here :

Could this be a dupe of Bug 405357 ?
Keywords: crash
Duping to Bug 405357 because i did tests with this bug and Bug 405357 and got the identical crash stacks. 

Also the tryserver build from jst fixes the crash for me :)
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 405357

Comment 17

10 years ago
I just wanted to drop a quick line to let everyone know that I tested this fix with the May 07 nightly and it appears to have indeed resolved it!! Thank you to everyone for your help in resolving this important bug.
You need to log in before you can comment on or make changes to this bug.