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
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.
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/
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.