Last Comment Bug 653116 - use plugin with most recent modification date when multiple matches for MIME type
: use plugin with most recent modification date when multiple matches for MIME ...
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Josh Aas
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-27 07:54 PDT by Josh Aas
Modified: 2013-04-22 04:10 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
fixed
fixed


Attachments
fix v1.0 (8.31 KB, patch)
2011-05-11 22:55 PDT, Josh Aas
no flags Details | Diff | Review
fix v1.1 (8.78 KB, patch)
2011-05-21 12:14 PDT, Josh Aas
jst: review+
Details | Diff | Review
fix v1.2 (8.80 KB, patch)
2011-05-27 12:25 PDT, Josh Aas
bent.mozilla: review+
Details | Diff | Review
fix v1.3 (8.80 KB, patch)
2011-05-27 12:47 PDT, Josh Aas
no flags Details | Diff | Review

Description Josh Aas 2011-04-27 07:54:46 PDT
I'd like to make our plugin loading strategy use the most recently modified plugin when there are multiple MIME type matches. The idea is to allow an updated plugin with the version number in the name to be installed alongside and older version that might be in use, and have it be loaded at the same time if new instances are created before the browser is restarted. This would allow for updating a plugin without restarting the browser.
Comment 1 Josh Aas 2011-05-11 07:02:09 PDT
At a glance it looks like our code would prefer plugins with more recent modification dates already, but it doesn't work and the broken implementation is probably far more complicated than it needs to be.
Comment 2 Steven Michaud [:smichaud] (Retired) 2011-05-11 07:06:31 PDT
> use plugin with most recent modification date when multiple matches
> for MIME type

I posted a patch for this long ago.  I'll see if I can find the bug.
Comment 3 Josh Aas 2011-05-11 07:44:32 PDT
Would be cool if you could show me your existing patch but don't worry about updating it right now. A lot of the relevant code has changed in the past few months and I already have a new patch in the works.
Comment 4 Steven Michaud [:smichaud] (Retired) 2011-05-11 08:50:04 PDT
(Following up comment #2)

I finally found it -- the patch is at bug 520085.
Comment 5 Josh Aas 2011-05-11 22:55:54 PDT
Created attachment 531853 [details] [diff] [review]
fix v1.0

Inserting into a single-direction linked list by order of modification date isn't pretty but it works and it takes half the lines of code that our broken sorting took. At some point later on I'll convert the tag lists to normal arrays.
Comment 6 Josh Aas 2011-05-21 12:14:50 PDT
Created attachment 534244 [details] [diff] [review]
fix v1.1

Just rolling in one line of cleanup.
Comment 7 Josh Aas 2011-05-27 12:25:41 PDT
Created attachment 535710 [details] [diff] [review]
fix v1.2

Take some good advice on arrays from Ben Turner.
Comment 8 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-05-27 12:30:09 PDT
Comment on attachment 535710 [details] [diff] [review]
fix v1.2

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

r=me with this one little change:

::: dom/plugins/base/nsPluginHost.cpp
@@ +2061,5 @@
> +
> +  for (PRUint32 i = 0; i < pluginFiles.Length(); i++) {
> +    nsCOMPtr<nsILocalFile>& localfile = pluginFiles[i];
> +
> +    nsAutoString utf16FilePath;

Just nsString here.
Comment 9 Josh Aas 2011-05-27 12:47:32 PDT
Created attachment 535718 [details] [diff] [review]
fix v1.3
Comment 10 Josh Aas 2011-05-27 21:10:08 PDT
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/147bc646bcaa
Comment 11 Vlad [QA] 2011-08-19 04:50:19 PDT
How can this be verified? Can you please provide some STR.
Thanks
Comment 12 Josh Aas 2011-08-19 11:56:04 PDT
The easiest way to verify this is to look at about:plugins. Plugins should now always be ordered correctly from newest on top to the oldest on the bottom. That wasn't necessarily true with older builds, especially on machines with older profiles and plugin updates applied.
Comment 13 Vlad [QA] 2011-08-23 02:18:45 PDT
I have tested this on
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 beta 1 and everything is as expected.

Setting resolution to Verified Fixed
Comment 14 Paul van der Hulst 2012-05-04 02:11:00 PDT
Hello,

I agree that predictable order is better than unpredictable order, but even better is: user defined order.
The reason I'm saying this is that many file types can be opened with different viewers. Using the latest will for example result in a pdf file being opened with nitro one time and acrobat another time, depending on which was updated last. This is annoying when you expect to be able to add notes to a pdf (possible with nitro, but not with acrobat reader), or you may just prefer the user interface of one over the other (but want to keep the other as fall-back)

The bottom line is: since viewers of different manufacturers differ, the latest is not by definition the greatest.

A plausible scenario is that you want to open pdfs with nitro and keep acrobat for anything that nitro doesn't support. This requires nitro to always have priority over acrobat even if it is older.

I guess this requires some dialog with a list of the plugins which can be dragged to the correct position (priority)

Another solution might be to allow multiple plugin selections in the applications section in the options dialog. Now only one plugin is listed when multiple compatible plugins are available. I have the option to either select acrobat reader or the nitro plugin (which funnily does not open the document with the nitro plugin but the acrobat plugin, but that's an other bug)
My idea is:
- 1 or more external programs (but these are also accessible through 'use other...' so it is not an issue)
- plugin no 1 (e.g. nitro)
- plugin no 2 (e.g. acrobat reader)
- plugin no 3 (foxit?)
etc
- use other...

Please consider this

Best regards,

Paul van der Hulst
Comment 15 Brian Duddy 2013-04-18 17:45:05 PDT
After investigating various PDF plugins, it appears that this error has returned in Firefox 20. Nuance, Adobe, Nitro, and Foxit's plugins are right now prioritized in that same order, which is the reverse of the modification dates of their plugins. They are correctly displayed from newest to oldest in about:plugins.

I was wondering, though - why not show all of the available plugins in the Options>Applications menu and allow the user to choose the one they prefer? Some of these PDF plugins and certainly other plugins can open multiple types of files, and users might want to choose one plugin for one type and another plugin for another type. The default behavior could be the (corrected!) last-modified sorting.
Comment 16 Georg Fritzsche [:gfritzsche] 2013-04-19 08:51:30 PDT
(In reply to Brian Duddy from comment #15)
> After investigating various PDF plugins, it appears that this error has
> returned in Firefox 20. Nuance, Adobe, Nitro, and Foxit's plugins are right
> now prioritized in that same order, which is the reverse of the modification
> dates of their plugins. They are correctly displayed from newest to oldest
> in about:plugins.

There were a few changes on the "preferred plugin" selection in the meantime. Could you please file a new bug on this?
Comment 17 Georg Fritzsche [:gfritzsche] 2013-04-19 08:56:48 PDT
(In reply to Brian Duddy from comment #15)
> I was wondering, though - why not show all of the available plugins in the
> Options>Applications menu and allow the user to choose the one they prefer?
> Some of these PDF plugins and certainly other plugins can open multiple
> types of files, and users might want to choose one plugin for one type and
> another plugin for another type. The default behavior could be the
> (corrected!) last-modified sorting.

Also, this would probably best filed as a separate bug. I think this would belong in the Firefox product, not sure which component though (General or Preferences?).
Comment 18 Brian Duddy 2013-04-19 10:01:30 PDT
(In reply to Georg Fritzsche [:gfritzsche] from comment #17)
> (In reply to Brian Duddy from comment #15)
> > I was wondering, though - why not show all of the available plugins in the
> > Options>Applications menu and allow the user to choose the one they prefer?
> > Some of these PDF plugins and certainly other plugins can open multiple
> > types of files, and users might want to choose one plugin for one type and
> > another plugin for another type. The default behavior could be the
> > (corrected!) last-modified sorting.
> 
> Also, this would probably best filed as a separate bug. I think this would
> belong in the Firefox product, not sure which component though (General or
> Preferences?).

Looking again, this appears to have already been reported a year ago as https://bugzilla.mozilla.org/show_bug.cgi?id=744299
Comment 19 Brian Duddy 2013-04-19 13:48:47 PDT
An update: After some more testing, it appears that, as Benjamin Smedburg said in the comments for Bug 863773, the plugin displayed in Options>Applications is not the same one Firefox uses (I didn't notice it earlier, some of these plugins have pretty minimal interfaces...) The order Firefox actually prioritizes them in appears to be Acrobat, then Nitro, then Foxit, then Nuance (which may not be working, but whatever). The only possible pattern I can find in this is the version number - Adobe is highest, Nuance is lowest, and so on.
Comment 20 Benjamin Smedberg [:bsmedberg] 2013-04-19 14:02:37 PDT
That is correct. The behavior in this bug was replaced by the behavior of bug 686335 which uses the plugin with the highest version number. Our plugin host is not really designed to deal with multiple plugins for the same type, and the recommended way for you to choose a "preferred" plugin is simply to disable all the other ones using the addons manager.

Note You need to log in before you can comment on or make changes to this bug.