226899 - Should continue to start even if plugin library / DLL load fails

Status: RESOLVED EXPIRED

(Core Graveyard :: Plug-ins, enhancement)

Description

[Jonathan Amir]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007

I am using mozilla 1.5 in a unix environment at a university.  There are a few
servers that I can log in to, running on Solaris and linux, and in all of them
my home directory is the same (and hence my ~/.mozilla/plugins directory is the
same). However, the mozilla 1.5 binary on each of the machines is of course
different.  I installed the latest flash plugin for linux (version 6.0 r79) in
my ~/.mozilla/plugins directory. This causes mozilla to crash whenever I run it
from the solaris machines - I think because of binary incompatibility.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Actual Results:  
Mozilla gives the following error message and does not terminate:

LoadPlugin: failed to initialize shared library
/h/43/jamir/.mozilla/plugins/libflashplayer.so [ld.so.1: ./mozilla-bin: fatal:
/h/43/jamir/.mozilla/plugins/libflashplayer.so: wrong ELF data format: ELFDATA2LSB]

Expected Results:  
I would like mozilla to continue loading, while disabling the particular plugin
which is "bad".  I would also expect the about:plugins page to reflect that
information - i.e. showing the plugin in the list and have it labeled as "disabled".

If that is not possible I would expect mozilla to exit gracefully ... instead of
forcing me to kill the process myself

Comment 1

[Malcolm Rowe]

I think there's a general bug about 'isolating plugin crashes from Mozilla', but
I can't find it at the moment. We probably can't do anything about plugins that
acutally crash the process during load, but we might be able to fix this problem.

I don't know about Linux, but on Windows we load the plugin with LoadLibrary (I
think), and that loads all dependent code and runs some initialisation.  It's
possible for LoadLibrary to fail, if (for example) the dependencies don't exist.
In this case, the application can still carry on, provided that the aborted
initialisation didn't break the application in some way.

[Not that I'm suggesting that we *do* do this on Windows, just that I know it'd
be possible.]

If Linux is anything like Windows (in that failing to load a shared library
isn't guaranteed to be fatal), I don't see why we couldn't skip the plugin and
carry on.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.