558462 - Should do something sensible when plugin binaries and Firefox are not using the same architecture

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[(no longer active)]

I tried installing a 64-bit en-US Firefox nightly on Ubuntu 9.10 x86-64, and it prompted me to install Flash when I visited youtube, and I clicked through the wizard and installed it.

Then I installed a 32-bit fa Firefox nightly, and noticed that flash doesn't load, and mozilla-runtime isn't running.  I got a lot of errors like this on the console:

LoadPlugin: failed to initialize shared library /var/lib/flashplugin-installer/npwrapper.libflashplayer.so [/var/lib/flashplugin-installer/npwrapper.libflashplayer.so: wrong ELF class: ELFCLASS64]

Here's the info about my flash player binary:

ehsan@ehsan-ubuntu:~/fa$ dpkg -l | grep flash
ii  flashplugin-installer                10.0.45.2ubuntu0.9.10.1                    Adobe Flash Player plugin installer
ehsan@ehsan-ubuntu:~/fa$ file /var/lib/flashplugin-installer/npwrapper.libflashplayer.so 
/var/lib/flashplugin-installer/npwrapper.libflashplayer.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

We should do something sensible here.  From the user's standpoint, the sensible thing to do is for Flash to work.  In order to do that, we need to ship both a 32-bit and 64-bit version of mozilla-runtime.

If that's not possible, we should at least show some sort of an error message to the user.

At the current state of things, it seems to the user that OOP is broken.

Comment 1

[(no longer active)]

Also:

ehsan@ehsan-ubuntu:~/fa$ dpkg -l | grep nspl
ii  nspluginwrapper                      1.2.2-0ubuntu6                             A wrapper to run Netscape plugins on other a

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The underlying problem here actually doesn't have anything to do with OOPP, but rather with the way that ubuntu's addon installs flash on linux x86-64.  I filed https://bugs.launchpad.net/ubuntu/+bug/559696 for that problem.

A simple workaround is to run
  $ ln -s /usr/lib/flashplugin-installer/libflashplayer.so ~/.mozilla/plugins/libflashplayer.so
after the ubuntu installer finishes.

I'm not really sure in which direction to take this bug, but we can leave it open to at least track the ubuntu issue.  I'd rather not make this bug "support mismatched firefox/plugin architectures", that's a lot to bite off.

Comment 3

[(no longer active)]

Chris, could you please paste the link to the Ubuntu bug you filed here?

Comment 4

[(no longer active)]

(In reply to comment #3)
> Chris, could you please paste the link to the Ubuntu bug you filed here?

Heh, my glasses seem to have crashed.  Restarting...

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking as per comment 2

Comment 6

[Josh Aas]

We probably want something like my patch for bug 551471, but for Linux. Mac OS X already does a check like that. Trusting installers to do the right thing is not a good plan.

Comment 7

[Johnny Stenback (:jst)]

Not blocking 1.9.3 either, also based on comment 2.

Comment 10

[David Bruant]

For anyone passing by this bug, the following add-on saved the day as a short-term workaround https://addons.mozilla.org/en-US/firefox/addon/flash-aid/

Comment 11

[Georg Fritzsche [:gfritzsche]]

Taking this so i think of it when i have time.

Comment 12

[Georg Fritzsche [:gfritzsche]]

While the rejection of incompatible archs would be easy to do as on OS X:
http://dxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginsDirDarwin.cpp#l357

... we are currently missing an implementation for GetArchitecturesForBinary() on non-OSX platforms:
http://dxr.mozilla.org/mozilla-central/source/ipc/glue/GeckoChildProcessHost.cpp#l220

... probably using libelf to do the check. As far as i can tell we don't have code to base this on yet in the codebase.

Comment 13

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.