815116 - Firefox 17 does not prefer plugins from $HOME/.mozilla/plugins

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Andreas Pakulat]

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

Steps to reproduce:

Start Firefox, check about:plugins (after setting plugin.expose_full_path).
Load a Flash page
Check lsof | grep flashplayer.so


Actual results:

Firefox showed that libflashplayer.so was loaded from /usr/lib/flashplugin-nonfree in about:plugins instead of $HOME/.mozilla/plugins.

Both plugins where listed but lsof confirmed that the one listed at the top was the one being loaded when visiting a flash site


Expected results:

Firefox should prefer plugins from $HOME/.mozilla/plugins to allow a user to install an update even if he has no admin privileges.

Firefox 16 and older did prefer plugins in the home directory

Comment 1

[Matthias Versen [:Matti]]

Could you try to find the regression range ?
we have an automated tool for such a task: http://mozilla.github.com/mozregression/

Comment 2

[Benjamin Smedberg]

Spefically, we'd like to find the regression range in the Firefox nightly builds, which should help us pinpoint the change which caused this more accurately.

Comment 3

[Matthias Versen [:Matti]]

I tested on my Ubuntu box
first I did a "cp /usr/lib/flashplayer-installer/libflashplayer.so ~/.mozilla/plugins"
Firefox found both flash player version and listed both in about:plugins

loading http://youtube.com and  "lsof | grep flashplayer.so":
firefox   10795      matti  mem       REG        8,1 17410532     833112 /home/matti/.mozilla/plugins/libflashplayer.so

This looks wfm

Comment 4

[Georg Fritzsche [:gfritzsche]]

Bug 686335 and bug 776923 are probable candidates here. If i remember correctly we now prefer the most recently modified plugin regardless of location.

Comment 5

[Andreas Pakulat]

Indeed it was the modification time, I thought I checked this prior to creating the report but either I forgot or I misinterpreted the ls output.

This is still somewhat problematic IMHO since its very hard to find anything about this change and more importantly a tar -xzf does not touch the extracted files so my local version could still be newer than the system version but not picked up because the system was installed after the release of the plugin (from older install media). Or the system version was touched for some other reason (it seems debians flashplugin-nonfree package touches the flashplayer file).

Comment 6

[Benjamin Smedberg]

Note that in bug 686335 we don't prefer the plugin with the newest mtime, we prefer the plugin with the most recent *version number*.

Comment 7

[Andreas Pakulat]

Hmm, ok, I guess that means this really only affects the Flash player then. My particular case is that I'm installing the debug-version of flashplayer in my home and have the same version of flashplayer, but non-debug, in /usr/ from my packages.

So maybe a rather esoteric case in which its fine to require the user to touch the local file. It would be good though if it were easier to find out that this is needed, other than filing a bugreport. I did not see anything even with NSPR_LOG_MODULES=all:5 set either.

Comment 8

[Georg Fritzsche [:gfritzsche]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> Note that in bug 686335 we don't prefer the plugin with the newest mtime, we
> prefer the plugin with the most recent *version number*.

Right, sorry, we still do. In the case of multiple matches with the most recent version number we pick the first from the list, which is ordered by mtime.

So this is really an edge-case which should only occur for developers.

Comment 9

[Mihai Morar, (:MihaiMorar)]

WFM for Ubuntu x86 on Latest Nightly (17/12/2012)

Comment 10

[BMO Automation]

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