plugins disabled by Aurora 21.x

VERIFIED FIXED in Firefox 21

Status

()

defect
P2
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: landis, Assigned: benjamin)

Tracking

21 Branch
mozilla22
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox21+ verified)

Details

Attachments

(1 attachment)

Reporter

Description

6 years ago
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)
Reporter

Comment 1

6 years ago
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.
Blocks: metro-build
Component: Untriaged → Plug-ins
Product: Firefox → Core
The fix in that thread is correct, <install>/plugins is no longer scanned. You can use your home folder or <install>/browser/plugins/.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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?
(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.
(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?
(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.
Assignee

Comment 7

6 years ago
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.
Assignee

Updated

6 years ago
Assignee: nobody → benjamin
Priority: -- → P2
Assignee

Comment 8

6 years ago
Attachment #721230 - Flags: review?(mh+mozilla)
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.
Attachment #721230 - Flags: review?(mh+mozilla) → review+
Assignee

Comment 11

6 years ago
Landis, this should be in tomorrow's nightly. Can you flip this pref on and then test whether the plugins are loaded correctly?
Flags: needinfo?(landis)
Keywords: qawanted
Landis, any luck trying this in the latest Nightly?
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
QA Contact: paul.silaghi
bsmedberg, this landed with the wrong bug number (bug 844533). 
Want to backout & reland, do something else or should i?
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.
Assignee

Comment 16

6 years ago
Yeah, I'm not sure why the mozilla-central merge didn't mark it so.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Assignee

Comment 17

6 years ago
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
Attachment #721230 - Flags: approval-mozilla-aurora?
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.
Flags: needinfo?(landis)
Keywords: qawantedverifyme
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 .
Attachment #721230 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee

Comment 20

6 years ago
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.
Verified fixed Aurora 21.0a2 (2013-03-27) Ubuntu 12.04 LTS.
Status: RESOLVED → VERIFIED
Keywords: verifyme

Updated

6 years ago
Depends on: 872389

Updated

6 years ago
No longer depends on: 872389

Comment 22

6 years ago
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.
Assignee

Comment 23

6 years ago
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.
You need to log in before you can comment on or make changes to this bug.