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




9 years ago
6 months ago


(Reporter: Ehsan, Unassigned)


Dependency tree / graph
Bug Flags:
firefox-backlog -

Firefox Tracking Flags

(blocking2.0 -, blocking1.9.2 -)


(Whiteboard: [lorentz])



9 years ago
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/ [/var/lib/flashplugin-installer/ wrong ELF class: ELFCLASS64]

Here's the info about my flash player binary:

ehsan@ehsan-ubuntu:~/fa$ dpkg -l | grep flash
ii  flashplugin-installer                          Adobe Flash Player plugin installer
ehsan@ehsan-ubuntu:~/fa$ file /var/lib/flashplugin-installer/ 
/var/lib/flashplugin-installer/ 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

9 years ago

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


9 years ago
Blocks: 478976
Whiteboard: [lorentz]
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 for that problem.

A simple workaround is to run
  $ ln -s /usr/lib/flashplugin-installer/ ~/.mozilla/plugins/
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

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

Comment 4

9 years ago
(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...
Not blocking as per comment 2
blocking1.9.2: ? → -

Comment 6

9 years ago
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.
Not blocking 1.9.3 either, also based on comment 2.
blocking2.0: ? → -


7 years ago
Duplicate of this bug: 667221


6 years ago
Duplicate of this bug: 808304

Comment 10

6 years ago
For anyone passing by this bug, the following add-on saved the day as a short-term workaround
Taking this so i think of it when i have time.
Assignee: nobody → georg.fritzsche
Priority: -- → P3
While the rejection of incompatible archs would be easy to do as on OS X:

... we are currently missing an implementation for GetArchitecturesForBinary() on non-OSX platforms:

... 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.
Assignee: georg.fritzsche → nobody
Severity: major → normal
Flags: firefox-backlog?


5 years ago
Flags: firefox-backlog? → firefox-backlog+


5 years ago
Flags: firefox-backlog+ → firefox-backlog-
You need to log in before you can comment on or make changes to this bug.