29688 - top talkback -Crash when encounter applet and Java not installed

Status: VERIFIED FIXED

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

Description

[Phil Peterson]

Using 2/29 build on Windows NT

1. Install Seamonkey without Java
2. Read warren's digitalMASS email 
3. Boom.

Talkback ID 6082790 shows nsPluginInstanceOwner::GetParameter() on the tip of 
the stack trace.

Comment 1

[Phil Peterson]

Attachment: Full stack trace

Comment 2

[Phil Peterson]

Attachment: Message which crashes

Comment 3

[drapeau]

Will try to get to it soon, but right now, verifying that the Java VM is working
well is the top priority.

Comment 4

[Phil Peterson]

cc [e-mail] on the chance that this is a plugins issue rather than an OJI
issue.

Comment 5

[Phil Peterson]

I crashed again on http://www.widespreadpanic.com trying to load a page with a 
Java applet. Same stack trace. I'm getting the feeling that we just don't work 
without Java. If that's the case, I think we should consider this bug for beta1.

Comment 6

[Phil Peterson]

Reassign to av, cc amusil

Comment 7

[av (gone)]

phil, I have trouble reproducing it. What exactly should I do?

Comment 8

[Phil Peterson]

1. Install Seamonkey without Java
2. Load http://www.widespreadpanic.com
3. Click on image to enter site
4. boom

Comment 9

[chris hofmann]

Attachment: some user comments/site info about this crash

Comment 10

[chris hofmann]

http://climate/reports/reporttemplate.cfm?style=0&reportID=1090
found 5.0nsPluginInstanceOwner::GetPar (170 Incidents)  in the database.
looks like some form of this crash happens on several sites with
several m14 and post m14 users

Comment 11

[av (gone)]

phil, I still see no boom. Is there any chance that SeaMonkey is trying to pick 
up older Java plugin from 4.x installation, which is known to be incompatible? I 
don't have it on my machine maybe this is a reason I don't crash. Could you try 
to, say, rename plugin folder in your 4.x install and see if you still crash?

Comment 12

[Phil Peterson]

Yep, that seems to be the root of the problem. I renamed the Plugins directory
from 4.72 and didn't crash. Then I renamed it back again, and we crashed again.

Not sure what you mean by "known to be incompatible" though. Seems like
Seamonkey has to run on machines which have 4.x installed on them...

Comment 13

[av (gone)]

Right. But is not it going to be distributed with Java?

Comment 14

[Phil Peterson]

Let me re-state: Seems like Seamonkey without Java has to run on machines which
have 4.x installed on them. There are several installation options which do not
include Java.

If you believe that crashing when Java is not installed is ok for beta1, you can
remove the PDT+ and the PDT will reevaluate the bug in light of what we've learned.

Comment 15

[av (gone)]

Hm... As per current implementation, SeaMonkey looks for plugins in 4.x 
installation too. Option of 'not including Java' sounds weird to me now. Adding 
ekrock.

Adding [e-mail] to the cc list. George, I think new Java plugin works 
with 4.x. Would it make sense to replace the older one in 4.x installation 
during SeaMonkey install?

Comment 16

[drapeau]

av: I'll ask the JDK product folks for their opinion on this.  It's not really
my call, although your idea is an interesting one.  I don't know if it fixes
this bug, but I do like the idea that people would have a single Java plug-in
for both versions of the browser.

Comment 17

[Phil Peterson]

Can't we fix Seamonkey so it only accepts a compatible Java plugin?

I'd sure hate to have Seamonkey potentially disable 4.x installations if
whacking the 4.x Java with a new Java didn't work. Unless that's had a ton of
testing I'm not aware of, it seems pretty high risk.

Comment 18

[ekrock's old account (dead)]

Agree with Phil that we should definitely not incur the added risk for beta1 of 
having the Seamonkey installer overwrite whatever Java-support plug-in is 
present in the Nav4 installation. There is simply too high a risk of hosing 
someone's Nav4 installation and no time to test this.

Instead, we need to make sure that the plug-in detection code (which currently 
scans the mozilla plugins directory first, then the Nav4 plugins directory) 
ignores any Java plug-in found in Nav4. Can this be easily done?

Comment 19

[av (gone)]

Yes, it's sorta one-liner. I can ignore npjava*.dll's in 4.x dir by their names. 
Alternatively, it can be done by mime types.

Comment 20

[av (gone)]

I have a fix. Can check it in as soon as I get it reviewed and approved.

Comment 21

[Sammy Ford]

does this also affect linux, cause the javaplugin from blackdown causes a crash
on startup. I thought the plugin arch was backwards compatible.

sPluginFile(/home/sford/mozilla/dist/bin/plugins/javaplugin.so)
LoadPlugin() /home/sford/mozilla/dist/bin/plugins/javaplugin.so returned 826a358

Comment 22

[Jim Roskind]

As of 3/9, this was listed as fix in hand, waiting for review.  Who is doing the
review and not responding?  We need to get this landed... the beta  train needs
to chug along.
Thanks,
Jim

Comment 23

[av (gone)]

I will check it in today.

Comment 24

[Alex Musil]

av - let me know if you need a review

Comment 25

[av (gone)]

The fix is in both the branch and the tip.

Comment 26

[Paul Wyskoczka]

Verified.  No longer crashes in build 2000031506 beta build.  

Comment 27

[Phil Peterson]

Works for me now too, using the 3/16 beta1 branch build.