844553 - plugins disabled by Aurora 21.x

Status: VERIFIED FIXED

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

Description

[Landis Reed]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20130223 Firefox/21.0
Build ID: 20130223042647

Steps to reproduce:

installed / updated Aurora to 21.0a2 (2013-02-23)...


Actual results:

All plugins are disabled / Missing from Addons > Plugins


Expected results:

I installed the latest Java, created symlink to /usr/java/jre1.7.0_15/lib/i386/libnpjp2.so per Java instructions.. didn't work.
Created symlink to /usr/java/jre1.7.0_15/plugin/i386/ns7/libjavaplugin_oji.so per mozilla instructions.. 
Neither scenario works.
No plugins, java, vlc, flashplayer, etc..

Landis.
openSuSE 12.2 - KDE 4.8.5 - mozilla Aurora nightly (Not installed in system, but user dir)

Comment 1

[Landis Reed]

I moved plugins to /home/UserName/.mozilla/plugins and added same to path...
this works.

mozillazine/Bluefang helped me with this: http://forums.mozillazine.org/viewtopic.php?f=23&t=2667083 he gave me this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=755724

Landis.

Comment 2

[Jim Mathies [:jimm]]

The fix in that thread is correct, <install>/plugins is no longer scanned. You can use your home folder or <install>/browser/plugins/.

Comment 3

[Georg Fritzsche [:gfritzsche]]

(In reply to Jim Mathies [:jimm] from comment #2)
> The fix in that thread is correct, <install>/plugins is no longer scanned.
> You can use your home folder or <install>/browser/plugins/.

Was this intentional or does it need fixing?

Comment 4

[Jim Mathies [:jimm]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #3)
> (In reply to Jim Mathies [:jimm] from comment #2)
> > The fix in that thread is correct, <install>/plugins is no longer scanned.
> > You can use your home folder or <install>/browser/plugins/.
> 
> Was this intentional or does it need fixing?

Intentional but there's an open question as to how serious the fall out will be.

Comment 5

[Alex Keybl [:akeybl]]

(In reply to Jim Mathies [:jimm] from comment #4)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #3)
> > (In reply to Jim Mathies [:jimm] from comment #2)
> > > The fix in that thread is correct, <install>/plugins is no longer scanned.
> > > You can use your home folder or <install>/browser/plugins/.
> > 
> > Was this intentional or does it need fixing?
> 
> Intentional but there's an open question as to how serious the fall out will
> be.

How difficult would it be to fix without waiting to find out about the fall out?

Comment 6

[Jim Mathies [:jimm]]

(In reply to Alex Keybl [:akeybl] from comment #5)
> (In reply to Jim Mathies [:jimm] from comment #4)
> > (In reply to Georg Fritzsche [:gfritzsche] from comment #3)
> > > (In reply to Jim Mathies [:jimm] from comment #2)
> > > > The fix in that thread is correct, <install>/plugins is no longer scanned.
> > > > You can use your home folder or <install>/browser/plugins/.
> > > 
> > > Was this intentional or does it need fixing?
> > 
> > Intentional but there's an open question as to how serious the fall out will
> > be.
> 
> How difficult would it be to fix without waiting to find out about the fall
> out?

Not difficult, but the question is do we want to? There are appropriate ways to register plugins with firefox, sticking a plugin dll in (firefox install)/plugins isn't one of them.

Comment 7

[Benjamin Smedberg]

I'll take this. What I want to do here is add code back to read the parentdir/plugins directory, but pref that off by default. This will give us the option to turn it back on in beta (or even on release via a hotfix) while keeping the desirable behavior for now.

Comment 8

[Benjamin Smedberg]

Attachment: Optionally load plugins from the appdir, rev. 1

Comment 9

[Mike Hommey [:glandium]]

Comment on attachment 721230 [details] [diff] [review]
Optionally load plugins from the appdir, rev. 1

Review of attachment 721230 [details] [diff] [review]:
-----------------------------------------------------------------

::: modules/libpref/src/init/all.js
@@ +1780,5 @@
>  // Disabled on all platforms per bug 705748 until the found issues are
>  // resolved.
>  pref("hangmonitor.timeout", 0);
>  
> +pref("plugins.load_appdir_plugins", false);

I think at some point we'll need to adapt terminology.
"appdir" is getting ambiguous.

Comment 10

[Benjamin Smedberg]

https://hg.mozilla.org/integration/mozilla-inbound/rev/64a876006908

Comment 11

[Benjamin Smedberg]

Landis, this should be in tomorrow's nightly. Can you flip this pref on and then test whether the plugins are loaded correctly?

Comment 12

[u279076]

Landis, any luck trying this in the latest Nightly?

Comment 13

[u279076]

Paul can you please try to replicate Landis' environment and see if you can reproduce this? If you are able to reproduce it with the Aurora build as indicated in comment 0 please test with the latest Nightly to see if you can replicate. We also need you to check if setting plugins.load_appdir_plugins to true makes a difference.

Thank you

Comment 14

[Georg Fritzsche [:gfritzsche]]

bsmedberg, this landed with the wrong bug number (bug 844533). 
Want to backout & reland, do something else or should i?

Comment 15

[Paul Silaghi, QA [:pauly]]

Indeed, if I change the symbolic link
ln -s /opt/java/32/jre1.7.0_15/lib/i386/libnpjp2.so ~/.mozilla/plugins/ 
with
ln -s /opt/java/32/jre1.7.0_15/lib/i386/libnpjp2.so ~/Desktop/aurora\ 2013-02-23/plugins/
the java plugin is not displayed in Addons Manager.

(In reply to Landis Reed from comment #0)
> Actual results:
> All plugins are disabled / Missing from Addons > Plugins
I couldn't reproduce this behavior. All my other plugins remains the same (adobe reader, vlc, quicktime, flash, wmp etc). But these plugins are different, I think they don't require additional symbolic links in order to be recognized by Firefox.

On Nightly 22.0a1 (2013-03-21), if I set plugins.load_appdir_plugins to true, java shows up in Addons Manager. So, I would say this bug is fixed.

Comment 16

[Benjamin Smedberg]

Yeah, I'm not sure why the mozilla-central merge didn't mark it so.

Comment 17

[Benjamin Smedberg]

Comment on attachment 721230 [details] [diff] [review]
Optionally load plugins from the appdir, rev. 1

Bug caused by (feature/regressing bug #):  Metro build-config change
User impact if declined: Hidden feature to re-enable plugins that previously worked is not present
Testing completed (on m-c, etc.): QA verified in bug
Risk to taking this patch (and alternatives if risky): Doesn't seem risky to me
String or UUID changes made by this patch: None

Comment 18

[u279076]

Thank you Paul for testing this. Benjamin, given Paul's testing I'm canceling your needinfo request; please correct me if this is still needed.

Paul, assuming this gets approval for Aurora and lands in the coming days, please verify it fixed. Thank you.

Comment 19

[bhavana bajaj [:bajaj]]

Comment on attachment 721230 [details] [diff] [review]
Optionally load plugins from the appdir, rev. 1

Restoring enable plugins feature via a pref which was default prior to Fx21 and was in this state due to Metro build-config change.Fix verified by qa on m-c approving for uplift.

:bsmedberg can you please help any additional test cases around this to QA if needed .

Comment 20

[Benjamin Smedberg]

https://hg.mozilla.org/releases/mozilla-aurora/rev/5251e66d26c3

I don't think there are any further testcases to verify other than making sure that plugins installed into appdir/plugins are only visible in about:plugins when the pref is true.

Comment 21

[Paul Silaghi, QA [:pauly]]

Verified fixed Aurora 21.0a2 (2013-03-27) Ubuntu 12.04 LTS.

Comment 22

[Carl]

Ok this would explain now why I'm having to manually enable plugins.load_appdir_plugins in about:config for all the installations of firefox version 21.  I would really like to hear the reasoning behind this.

Quicktime and windows media player both install to the <install>/plugins directory.  And the install requests administrative privileges so that all users on the computer get the plugin.  How do you expect an install that is ran with administrative privileges to make itself available to all users if it has to be installed to a directory under each user?  I'm referring to the new plugin path C:\Users\<username>\AppData\Roaming\Mozilla\Plugins.

Isn't this also a security risk in that software can now install plugins for firefox without having to get administrative privileges?  Any software the user runs can now copy a plugin to the local user plugin path.  At least before, you needed permission to install a plugin.

I believe this was rushed too quickly and at the very least, the plugins that use the <install>/plugins directory should have been notified of the change.  That being quicktime and the windows media player plugins.

But now I gotta worry about plugins being silently installed when I test out a piece of software when it doesn't ask for administrative privileges.

I'd like it if I could disable the C:\Users\<username>\AppData\Roaming\Mozilla\Plugins like I can enable the <install>/plugins directory.

Comment 23

[Benjamin Smedberg]

We expect plugins to install using the standard registry keys: https://developer.mozilla.org/en-US/docs/Gecko_Plugin_API_Reference/Plug-in_Development_Overview#Windows_Installation_Using_the_Registry

We asked plugin vendors to stop shoving plugins into our install directory several years ago, because it affects our ability to make changes, such as this Metro change, but also changes about how we apply updates.

The WMP plugin is unmaintained, as far as we can tell.