Top crash [@ npjava13.dll@0x1674 ] - [@ NPJava13.dll@0x12e7 ] - [@ npjava11.dll@0x1674 ] - [@ npjava11.dll@0x1674 ]

VERIFIED FIXED in mozilla1.9.2



10 years ago
8 years ago


(Reporter: cbook, Assigned: jaas)


({crash, topcrash})

1.9.2 Branch
Windows XP
Dependency tree / graph
Bug Flags:
blocking1.9.2 +

Firefox Tracking Flags

(status1.9.2 beta4-fixed)


(Whiteboard: [crashkill][crashkill-thirdparty], crash signature)


(1 attachment)



10 years ago
currently #9 of the Firefox 3.6 Beta 1 TopCrashes

npjava13.dll belongs to Sun's JRE 

A lot of this Crashes seems to be startup Crashes and comments mentioned steps to reproduce like "clicked on "add photos" in facebook" 

Version id of this DLL is npjava13.dll
Flags: blocking1.9.2?


10 years ago
Whiteboard: [crashkill]
Josh, isn't this an old Java plugin that's being loaded? Didn't we block them from loading?
Assignee: nobody → joshmoz
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.2
Odd that these start with FF 3.6.  There don't seem to be any on the 1.9.1 and 1.9.0 branches.

Comment 3

10 years ago
It is because we removed support for the old Java plugin in Firefox 3.6.

Comment 4

10 years ago
In nsPluginsDirWin.cpp:192, in "nsPluginsDir::IsPluginFile",  we stop "npoji.dll" from loading. This was part of bug 488042. Maybe we should also look for things starting with "npjava" and not load those either, but I need to investigate more. I don't know what "npjava13" is, maybe Sun renamed "npoji.dll"?

Comment 5

10 years ago
npjava*.dll are used to provide mime type information to browsers and hold entry points to plugin DLLs for the func table used by mozilla. Multiple such dlls exist because of an historical limit on the MIME type length in Windows 98. Since java 6.0 update 10, those dlls are consolidated to the npjpixxx_xx.dll (xxx_xx is the version string like 160_16).

Comment 6

10 years ago
This might be what we want, I still need to test on Windows.

Comment 7

10 years ago
since we have removed support for java this definitely sounds like a candidate
for blocking.

distribution of all versions where the npjava crash was found on
 374 Firefox 3.6b1
  18 Firefox 3.7a1pre
   5 Firefox 3.6a1

signature list
 263 npjava13.dll@0x1674
 113 NPJava13.dll@0x12e7
  83 npjava11.dll@0x1674
  52 NPJava11.dll@0x12e7
  47 npjava14.dll@0x1674
  28 NPJava14.dll@0x12e7
   4 npjava32.dll@0x1674
   1 NPJava32.dll@0x12e7
Whiteboard: [crashkill] → [crashkill][crashkill-thirdparty]

Comment 8

10 years ago
(In reply to comment #7)
> since we have removed support for java this definitely sounds like a candidate
> for blocking.

i agree - also crash statistics list more crashes - adding them to the bug so that they are linked from crash stats to this bug
Summary: TopCrash [@npjava13.dll@0x1674 ] → TopCrash [@npjava13.dll@0x1674 ] - [@NPJava13.dll@0x12e7 ] - [@npjava11.dll@0x1674 ] - [@npjava11.dll@0x1674 ]


10 years ago
Attachment #411529 - Flags: review?(jst)

Comment 9

10 years ago
Comment on attachment 411529 [details] [diff] [review]
don't load npjava*.dll, v1.0

This seems to work, though I don't have a Java install with npjava* DLLs.

I'm not sure why the crashing browsers are trying to load those DLLs directly, I've only seen npoji*.dll, npdeploytk.dll, and npjp2.dll loaded before (showing up in about:plugins).

Hao - I still don't understand the role of npjpixxx_xx.dll and npjava*.dll. Those aren't detected as plugins in Firefox, or at least they aren't found via the registry under normal circumstances.
Attachment #411529 - Flags: review?(jst) → review+


10 years ago
Depends on: 525103
I have an old, Java 1.5/5.0 (U13) installation on Windows.  With it,
the following DLLs all show up in about:plugins:


Somebody should try Java 1.4.2, and see what shows up.
Here is what I see with 1.4.2 on my lab Win XP Machine:

File: NPJava11.dll
File: NPJava12.dll
File: NPJava13.dll
File: NPJava14.dll
File: NPJava32.dll
File: NPJPI142.dll
Sorry, forgot to include the fact I was running  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b2) Gecko/20091108 Firefox/3.6b2 (.NET CLR 3.5.30729) when I crashed.
Marcia, I imagine any Java applet would crash.  Is that true?

Yes, that is what jst was saying. That site doesn't crash, but instead shows the missing plugin icon. When I go to it says java is not working.

He told me to keep this machine in ready state so I can test any patch that comes by.

(In reply to comment #14)
> Marcia, I imagine any Java applet would crash.  Is that true?
> Try

Comment 17

10 years ago
It could be that the two pages are essentially resolving from different MIME types (applet must have some default MIME type association, the other page uses "application/x-java-applet;version=1.4.1") and thus using different DLLs.
Here's a page that loads the same applet twice -- first using an
APPLET tag inside an OBJECT tag, then just using an APPLET tag.  The
OBJECT tag (which is the one that'd get used on Windows) doesn't
specify a particular Java version.

Marcia, please try this on your 1.4.2 box.
> (which is the one that'd get used on Windows)

Actually I'm not so sure about this.
My Java 1.5/5.0 U13 install (on Windows XP) crashes with this URL

but not with this one

I don't get a crash, but it gives me "No or unable to detect" and "Java isn't installed or doesn't work"
So it sounds like Josh's comment #17 is correct.

But that still needs confirmation.

Comment 23

10 years ago
do we have some  status white board flag for "this needs a beta"?   if we did should this bug get that flag? 

also what will the user experience be when we start doing the blocking?  will users be confused seeing the plugin finder when they know they have installed java in the past?  needs-userdoc to prepare for 3.6 support?
Keywords: user-doc-needed
The blocking we do we've been doing for quite some time on 1.9.2, this is just about blocking a few more cases (even older versions of Java), so I don't think this needs a beta. User docs would be good here though.

Comment 25

10 years ago
ok. thanks for clearifying.

I also talked to marcia about this just now.  sounds like we might need a bug or maybe more about how about:plugins deals with a disabled plugins.

maybe the short term is to just remove from the about:plugins for 3.6 to help clearify that the plugin is not loaded.

seems like the best solution is to continue to show disabled plugins as "installed -- but disabled"  as opposed to the current behavior that sounds like just showing as installed. 

the new addon/plugin/external module blocking system should also be tested for how it deals with about:plugins as well.

thoughts on this?  which bugs should we file?

Comment 26

10 years ago
pushed to mozilla-central
Will test this fix on the machine in the lab when the power is restored over the weekend.


10 years ago
Summary: TopCrash [@npjava13.dll@0x1674 ] - [@NPJava13.dll@0x12e7 ] - [@npjava11.dll@0x1674 ] - [@npjava11.dll@0x1674 ] → TopCrash [ @npjava13.dll@0x1674 ] - [ @NPJava13.dll@0x12e7 ] - [ @npjava11.dll@0x1674 ] - [ @npjava11.dll@0x1674 ]

Comment 28

10 years ago
pushed to mozilla-1.9.2
Closed: 10 years ago
Resolution: --- → FIXED
Verified fixed on the trunk using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091116 Minefield/3.7a1pre. No crash with the site noted in Comment 12. That site now loads with a puzzle piece in place of the content.
This landed after beta3 was tagged.

  -> final-fixed

Comment 31

10 years ago
what can we/are we going do about the UX problem of users seeing the puzzile piece when then know they have installed java in the past and they can see java installed in about:plugins ?

if there is a chance of that, or if we have seen evidence of users convinced of that I'll file other bug(s).  if not then all the issued raised here sound fixed and no more bug spin offs are required.

Comment 32

10 years ago
That only happens to people that don't have an older version of Java right? The crashing site in comment #12 uses a MIME type of "application/x-java-applet;version=1.4.1".

Comment 33

10 years ago
re: comment 32.  

not sure. marcia might know.

if it only happens to people that *don't* have the older version of java, what would the people that *do* have the older versions see?
When I was verifying the bug with an older version of Java (1.4.2), I do see the puzzle piece on sites such as the nintendo site and I think about:plugins does show java - I can check when I go back down to the lab.

Comment 35

10 years ago
With my patch you'd see the puzzle piece whether or not you have the old java whenever a plugin specifically requests and old java.
Re: user-doc-needed
If I understand correctly, this is a 3.6 bug and will be fixed in final release. We generally don't create documentation for issues that don't exist in end-user releases.
Keywords: user-doc-needed

Comment 37

10 years ago
cillas: the crash has been fixed.  the confusion user might have about having older java installed and seeing the new plugin finder when a page has java applets does not sound like it is fixed or will be fixed for 3.6.
Summary: TopCrash [ @npjava13.dll@0x1674 ] - [ @NPJava13.dll@0x12e7 ] - [ @npjava11.dll@0x1674 ] - [ @npjava11.dll@0x1674 ] → Top crash [@ npjava13.dll@0x1674 ] - [@ NPJava13.dll@0x12e7 ] - [@ npjava11.dll@0x1674 ] - [@ npjava11.dll@0x1674 ]
Crash Signature: [@ npjava13.dll@0x1674 ] [@ NPJava13.dll@0x12e7 ] [@ npjava11.dll@0x1674 ] [@ npjava11.dll@0x1674 ]
You need to log in before you can comment on or make changes to this bug.