currently #9 of the Firefox 3.6 Beta 1 TopCrashes http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6b1&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=npjava13.dll%400x1674 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 184.108.40.206
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.
It is because we removed support for the old Java plugin in Firefox 3.6.
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"?
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).
This might be what we want, I still need to test on Windows.
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 20091109-crashdata.csv 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]
(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 ]
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.
I have an old, Java 1.5/5.0 (U13) installation on Windows. With it, the following DLLs all show up in about:plugins: NPJava11.dll NPJava12.dll NPJava13.dll NPJava14.dll NPJava32.dll NPJPI150_13.dll NPOJI610.dll 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
Using the 1.4.2 version of Java I can reproduce this crash 100% of the time by simply visiting http://www.nintendo8.com/game/504/mega_man_6/. http://crash-stats.mozilla.com/report/index/bp-2a373df1-740e-4d17-a953-853162091111
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? Try http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html.
Yes, that is what jst was saying. That site doesn't crash, but instead shows the missing plugin icon. When I go to http://www.java.com/en/download/help/testvm.xml 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 http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html.
http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html and http://www.java.com/en/download/help/testvm.xml use an APPLET tag. http://www.nintendo8.com/game/504/mega_man_6/ uses an EMBED tag inside an OBJECT tag. I wonder if that's what makes the difference.
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. http://browserspy.dk/java.php 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 http://www.nintendo8.com/game/504/mega_man_6/ but not with this one http://browserspy.dk/java.php. bp-fc1d3c3f-4bec-4acf-93a3-a42f22091111
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.
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?
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.
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?
pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/6cf81d2d5d75
Will test this fix on the machine in the lab when the power is restored over the weekend.
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 ]
pushed to mozilla-1.9.2 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/adb46cd3b9f9
Status: NEW → RESOLVED
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.
Status: RESOLVED → VERIFIED
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.
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".
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.
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.
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.