top talkback -Crash when encounter applet and Java not installed



Core Graveyard
Java: OJI
18 years ago
7 years ago


(Reporter: Phil Peterson, Assigned: av (gone))



Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+] fix in hand (need review and approval))


(3 attachments)



18 years ago
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

18 years ago
Created attachment 5907 [details]
Full stack trace

Comment 2

18 years ago
Created attachment 5908 [details]
Message which crashes

Comment 3

18 years ago
Will try to get to it soon, but right now, verifying that the Java VM is working
well is the top priority.
Target Milestone: M16

Comment 4

18 years ago
cc on the chance that this is a plugins issue rather than an OJI

Comment 5

18 years ago
I crashed again on 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.


18 years ago
Keywords: beta1

Comment 6

18 years ago
Reassign to av, cc amusil
Assignee: drapeau → av
Summary: Crash when mail contains applet and Java not installed → Crash when encounter applet and Java not installed
Whiteboard: [PDT+]

Comment 7

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

Comment 8

18 years ago
1. Install Seamonkey without Java
2. Load
3. Click on image to enter site
4. boom

Comment 9

18 years ago
Created attachment 6255 [details]
some user comments/site info about this crash

Comment 10

18 years ago
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
Summary: Crash when encounter applet and Java not installed → top talkback -Crash when encounter applet and Java not installed

Comment 11

18 years ago
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

18 years ago
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

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

Comment 14

18 years ago
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

18 years ago
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 

Adding 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

18 years ago
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

18 years ago
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.
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?


18 years ago
Severity: major → critical
Keywords: crash

Comment 19

18 years ago
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

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


18 years ago
Whiteboard: [PDT+] → [PDT+] fix in hand


18 years ago
Whiteboard: [PDT+] fix in hand → [PDT+] fix in hand (need review and approval)

Comment 21

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

LoadPlugin() /home/sford/mozilla/dist/bin/plugins/ returned 826a358

Comment 22

18 years ago
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.

Comment 23

18 years ago
I will check it in today.

Comment 24

18 years ago
av - let me know if you need a review

Comment 25

18 years ago
The fix is in both the branch and the tip.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 26

18 years ago
Verified.  No longer crashes in build 2000031506 beta build.  

Comment 27

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


7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.