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/
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.
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.
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).
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*.
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.