Closed Bug 313650 Opened 19 years ago Closed 19 years ago

Camino 'quits unexpectedly' upon launching after downloading successfully and dragging icon to applications.

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jaime-lee.parkes, Assigned: mikepinkerton)

Details

(Keywords: crash)

Attachments

(1 file)

The report generated by Mac OSX in Text Edit format
26.38 KB, text/rtf
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 5.23; Mac_PowerPC)
Build Identifier: Version: 0.8.4 (0.8.4)

Camino crashes every time I try to launch it after downloading successfully and dragging icon to applications folder.  I have not manage to launch Camino once yet since downloading and have tried at least 10 times.

Reproducible: Always

Steps to Reproduce:
1.Download latest stable version from http://www.caminobrowser.org/
2.Double click .dmg from desktop
3.Drag icon to applications folder
4. Double click icon in aapplications folder.
5. The application Camino has quit unexpectedly

Actual Results:  
I have not suceeded in opening up a camino browser window.

Expected Results:  
Opened up a browser window
It's dying below JEPCreateJavaVMAndInitAWT. Do we always initialize Java on startup? Ouch, that seems slow.

Have you tried re-downloading Camino? It's possible, if unlikely, that something got corrupted on download and a fresh start might fix it. If it doesn't a workaround to get you going in the meanwhile might be to either remove the JEP, or disable Java. For either you probably want to seek help from http://forums.mozillazine.org/
Group: security
Keywords: crash
Reporter, your version of the Java Embedding Plugin in you ~/Library/Internet Plug-ins or /Library/Internet Plug-ins folder is too old (ancient!).  The current version is 0.9.5.

If you remove the MRJPlugin.plugin and the JavaEmbeddingPlugin.bundle from whichever of those folders they're in, Camino should start.  (Or you can use another browser to download the current JEP and install its version of those files; either way, Camino 0.8.4 should then start.)

(Also, in the future, please change the format of the crash log to Plain Text in Text Edit; thanks!)

Steven, Simon, is this invalid, or is there something we could/should be doing not to crash at startup in this situation?  Or are we already doing it in 1.0a1+?
Yes, I'd say this is invalid -- the reporter's version of the JEP (0.8.8) came
out before Tiger (OS X 10.4) was released, and is incompatible with it!  He
must (presumably) have recently upgraded his OS version.

As for why the crash happens on startup, I'm not really sure.

Before the fix for bug 128366 (around December 2004), all Mozilla-family
browsers loaded the x-java-vm/x-java-applet MIME type handler (in this case
the MRJ Plugin JEP) on startup, but didn't start the JVM.  When the MRJ Plugin
JEP starts up it loads JavaEmbeddingPlugin.bundle and runs some initialization
code in the latter.  But the call to JEPCreateJavaVMAndInitAWT only happens
when the JVM is being initialized.  I assume that the reporter's home page
contains a Java applet (or he might conceivably have set his home page to
about:plugins, which (wierdly) always tries to load an applet from an invalid
URL).

(Current browser versions only load the x-java-vm/x-java-applet MIME type
handler on demand.)
Attachment #200646 - Attachment mime type: text/plain → text/rtf
(In reply to comment #4)

> As for why the crash happens on startup, I'm not really sure.
> 
> Before the fix for bug 128366 (around December 2004), all Mozilla-family
> browsers loaded the x-java-vm/x-java-applet MIME type handler (in this case
> the MRJ Plugin JEP) on startup, but didn't start the JVM.

0.8.4 wouldn't have that fix, but if I understand the rest of your explanation, it still wouldn't explain this crash.

Reporter, what is your home page set to in Camino?


I have not been able to set a home page in Camino as I have not been able to launch it since installing.  My current browser, explorer, is set to google for a home page, but I don't know if this would carry across automatically. from reporter.
The most user-friendly workaround would be to display a dialogue saying that the user's version of JEP is to old, and information on how to upgrade it. Similar to the dialogue you get when you try to launch several instances of Camino at the same time.
> The most user-friendly workaround would be to display a dialogue saying that
> the user's version of JEP is to old, and information on how to upgrade it.

But how would the code that did this know a given JEP version was too old, or
somehow inappropriate?  And if you make the browser do this for the JEP, why
not make it do the same for _every_ plugin?

This would quickly become grossly overcomplicated, and is (I think) an
inappropriate solution to this problem.

For users sophisticated enough to know how to check which version they have of
which plugin, who know that upgrading OS versions can break things, and who
know (generally) how to upgrade plugins if they need to, I think things are
about as good as they need to be right now.  It helps that there is a _very_
good central warehouse of information at http://pluginsdoc.mozdev.org/.

For the naive user (someone who's relatively less sophisticated), probably the
only viable solution is to wait for copies of Firefox that contain recent,
usable versions of the Java Embedding Plugin to become more widespread and
easily available.


> And if you make the browser do this for the JEP, why
> not make it do the same for _every_ plugin?

Because _every_ plugin doesn't make the browser crash.

> For users sophisticated enough to know how to check which version they have of
> which plugin, who know that upgrading OS versions can break things, and who
> know (generally) how to upgrade plugins if they need to, I think things are
> about as good as they need to be right now.  It helps that there is a _very_
> good central warehouse of information at http://pluginsdoc.mozdev.org/.

So Camino should only be for "sophisticated" users? This is against every form of user-friendly design, most users are _not_ "sophisticated". Not "naive" either.

Typical case: You've heard about Camino, and people say it's much better than IE5 that you currently use. So you download Camino and launch it and BAM! It doesn't work, and you don't have any clue at all _why_ it doesn't work. So you throw out Camino and go back to IE5.

It's more than _obvious_ that a proper error message should be shown.
I'd say that the reporter has a couple of options.  The first is much simpler,
and is the one I'd try first:

1) Use another browser (such as Mac Internet Explorer) to download a more
   recent Camino version -- one that contains a recent enough version of the
   Java Embedding Plugin.  Camino 1.0 Alpha 1 contains JEP 0.9.3+b, which is
   recent enough to perform decently on Mac OS X 10.4.2 (the OS version the
   reporter now has).  You can get it from:

   http://www.caminobrowser.org/download/releases/1a1/

2) Use another browser to download the latest version of the Java Embedding
   Plugin from http://javaplugin.sourceforge.net/, then follow the Readme's
   instructions to install that to /Library/Internet Plug-Ins.


> It helps that there is a _very_ good central warehouse of information at
> http://pluginsdoc.mozdev.org/.

Sorry, I got this URL wrong.  It's http://plugindoc.mozdev.org/.  And it's
well worth checking out.


(In reply to comment #9)

> Typical case: You've heard about Camino, and people say it's much better than
> IE5 that you currently use. So you download Camino and launch it and BAM! It
> doesn't work, and you don't have any clue at all _why_ it doesn't work. So you
> throw out Camino and go back to IE5.

I'd argue that most people who are still using IE (or any other non-Gecko browser) won't have the JEP installed.  You don't learn about the JEP unless you hang around mozilla.org.  That said, I don't know why the reporter of this bug had the old version of JEP installed.

> It's more than _obvious_ that a proper error message should be shown.

And Safari should tell me why it fails on startup half the time when I send it an AppleEvent.  In a perfect world.  

Steven, can you replicate the crash?  Or, more importantly IMO, if you've got a recent Camino but with an older JEP (0.9.0 is incompat with 10.4, right, and 0.9.3 is incompat with 10.4.x's latest Java update?), does the recent Camino still crash at startup?  (I downloaded 0.8.8, removed existing JEPs from Plugins and the app bundle, and couldn't cause either Camino 0.8.4 or 1.0a1+ to crash on startup with 10.3.9 and the latest Apple Java update for 10.3.9, but I'm not sure that is a valid test.)

As long as we're reasonably certain that a user downloading, e.g., Camino 1.0 with bundled JPE 0.9.5 in January--after Apple has issued a new Java Update for 10.4.x, or an even more mythical one for 10.3.9--won't crash on startup, then I'm not much concerned with this crashing of 0.8.4 (other than ensuring the reporter is able to get a working Camino).

Reporter, please follow the steps outlined in comment 10 and let us know if you get Camino working; thanks!
> can you replicate the crash?

There's no need.  JEP 0.8.8 is incompatible with OS X 10.4.X (Tiger).  If I
remember correctly, the symptom was a particular kind of crash.  But in any
case it won't work.

> 0.9.3 is incompat with 10.4.x's latest Java update?

No.  So Camino 1.0 Alpha 1 (which bundles JEP 0.9.3+b) should work fine.  I
just tried it with OS X 10.4.2 with the latest Java stuff from Apple, and had
no problems.

> As long as we're reasonably certain that a user downloading, e.g., Camino
> 1.0 with bundled JPE 0.9.5 in January--after Apple has issued a new Java
> Update for 10.4.x, or an even more mythical one for 10.3.9--won't crash on
> startup

Unfortunately, there's no way to guarantee that.  Apple could break the JEP at
a moment's notice ... and has already done so twice (the first time was early
this year -- an update for OS X 10.3 broke signed applets).  The thing is to
try to convince them to test with the JEP, and not to blindside us/me again.
See bug 308549 for more information.

Furthermore, I _expect_ Apple's major updates (e.g. from OS X 10.3 to 10.4, or
from 10.4 to 10.5) to break the JEP.  The JEP must work at a low level, with
undocumented APIs -- the kinds of things that Apple has always changed from
major version to major version.  The most I can do is get hold of Apple's
developer seeds early enough for me to make the JEP work with the new version
before it comes out.  I underestimated the difficulty of doing that for OS X
10.4, and was a week late ... but in the grand scheme of things, being just a
week late wasn't really so bad :-)

By the way, I'm convinced that the reporter has set his home page to something
that launches Java (possibly to "about:plugins") -- there's really no other
plausible expanation for the crash taking place on startup.

Reporter:  Please download Camino 1.0 Alpha 1, as I've suggested.  Tell us
whether it works for you.  And tell us what page comes up the _second_ time
you start Camino (I don't know whether Camino, like many browsers, treats the
first launch after installation differently).


Thanks everyone the latest version recommended by you works and I got the camino home page the second time I opened up the browser.  As for your 'naive' and 'unsophisticated' users!!!!  I work as an IT analyst with PC's but am new to Macs.  Either way I am accustomed to Pc's advising what is needed in order to work an application and Macs 'guessing' what is needed. So with regard to the Mozilla team setting up some kind of error message, it's an absolute must in order for Camino to win recognition for it's user friendliness.  However if you want to develop a browser just for people like yourselves, Steven Michaud, please continue to be rude about me and others in your user base that bother to outline potential issues to you!
OK, we've verified the cause of the crash was a version of the JEP incompatible with the OS version, so closing this as Invalid.

We'll deal with the forward-looking stuff elsewhere.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: