If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

UNCONFIRMED
Unassigned

Status

()

Core
Plug-ins
UNCONFIRMED
5 years ago
5 years ago

People

(Reporter: Andreas Pakulat, Unassigned)

Tracking

17 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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
Component: Untriaged → Plug-ins
Product: Firefox → Core
Could you try to find the regression range ?
we have an automated tool for such a task: http://mozilla.github.com/mozregression/

Comment 2

5 years ago
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.
Flags: needinfo?(andreas)
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
Bug 686335 and bug 776923 are probable candidates here. If i remember correctly we now prefer the most recently modified plugin regardless of location.
(Reporter)

Comment 5

5 years ago
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).
Flags: needinfo?(andreas)

Comment 6

5 years ago
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*.
(Reporter)

Comment 7

5 years ago
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.
(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.
WFM for Ubuntu x86 on Latest Nightly (17/12/2012)
You need to log in before you can comment on or make changes to this bug.