use plugin with most recent modification date when multiple matches for MIME type

VERIFIED FIXED

Status

()

Core
Plug-ins
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: Josh Aas, Assigned: Josh Aas)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(firefox5 affected, firefox6 affected, firefox7 fixed, firefox8 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

8.78 KB, patch
jst
: review+
Details | Diff | Splinter Review
8.80 KB, patch
Ben Turner (not reading bugmail, use the needinfo flag!)
: review+
Details | Diff | Splinter Review
8.80 KB, patch
Details | Diff | Splinter Review
(Assignee)

Description

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

Comment 1

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

Comment 3

6 years ago
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.
(Following up comment #2)

I finally found it -- the patch is at bug 520085.
(Assignee)

Comment 5

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

Updated

6 years ago
Attachment #531853 - Flags: review?(benjamin)
(Assignee)

Comment 6

6 years ago
Created attachment 534244 [details] [diff] [review]
fix v1.1

Just rolling in one line of cleanup.
Attachment #531853 - Attachment is obsolete: true
Attachment #531853 - Flags: review?(benjamin)
Attachment #534244 - Flags: review?(benjamin)

Updated

6 years ago
Attachment #534244 - Flags: review?(benjamin) → review+
(Assignee)

Comment 7

6 years ago
Created attachment 535710 [details] [diff] [review]
fix v1.2

Take some good advice on arrays from Ben Turner.
(Assignee)

Updated

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

Comment 9

6 years ago
Created attachment 535718 [details] [diff] [review]
fix v1.3
(Assignee)

Comment 10

6 years ago
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/147bc646bcaa
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
status-firefox5: --- → affected
status-firefox6: --- → affected
status-firefox7: --- → fixed
status-firefox8: --- → fixed

Comment 11

6 years ago
How can this be verified? Can you please provide some STR.
Thanks
(Assignee)

Comment 12

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

6 years ago
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
Status: RESOLVED → VERIFIED

Comment 14

5 years ago
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

4 years ago
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.

Updated

4 years ago
status-firefox20: --- → ?
(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?
(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

4 years ago
(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

4 years ago
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

4 years ago
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.
status-firefox20: ? → ---
You need to log in before you can comment on or make changes to this bug.