520085 - Plugin priority incorrect on trunk and 1.9.2 branch (OS X and Linux)

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

The browser maintains a list of plugins that it can search to find a
plugin to handle a given MIME type.  The ordering of this list
determines which plugins have priority over other plugins that support
the same MIME type (all other things being equal).

There are a number of different places (directories) where the browser
looks for plugins.  These directories are searched in a
well-determined order -- so that plugins in certain locations are
always earlier in the plugins list (and have a higher priority) than
plugins in other locations.  For example, on OS X the browser searches
first in the distro's Contents/MacOS/plugins directory/, then in the
current user's ~/Library/Internet Plug-Ins/ directory, then in the
system-wide /Library/Internet Plug-Ins/ directory.

Within each of these directories, plugin priority is determined by 1)
the plugin's timestamp and 2) the plugin's filename (if two plugins'
timestamps are equal).

On the 1.9.1 branch and earlier, newer plugins are given higher
priority -- on the assumption that newer releases are more reliable.
But starting with part of the patch for bug 474369
(http://hg.mozilla.org/mozilla-central/rev/ea9c7c17e0c2, "get rid of
nsVoidArray, plugin part"), on both the trunk and the 1.9.2 branch,
*older* plugins are now given higher priority.

The code that loads plugins is very complex, and sometimes quite
obscure (and poorly commented).  There's no indication that this
change was intentional.  And in any case it's a bug, and should be
fixed.  I'll post a patch in a later comment.

Here's how to see the problem:

The list of plugins you get after entering about:plugins is in plugin
priority order -- plugins earlier in the list are given higher
priority (are checked first when looking for a plugin that can handle
a given MIME type).

On OS X most plugins are installed to /Library/Internet Plug-Ins/.  On
Linux most plugins are usually installed to the browser "bundle"'s
plugins directory (either the plugins themselves, or soft links to
them).  If soft links are present, the timestamp the browser uses (to
determine plugin priority) is that of the soft link's target (not the
soft link itself).

If you do about:plugins in (say) FF 3.5.3 on OS X and Linux, you'll
see that most plugins are listed in the order of their timestamps in
/Library/Internet Plug-Ins/ (on OS X) or in the browser bundle's
plugins directory (on Linux) -- the newest are listed first (as with
'ls -alt').  But if you do about:plugins in a recent trunk or
1.9.2-branch nightly, most plugins are listed in the reverse order of
their timestamps -- the oldest are listed first (as with 'ls -alrt').

This doesn't appear to happen on Windows -- I'm not entirely sure why.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix

I'm making some tryserver builds.

I'll ask for review after I've had a chance to play with the Linux and
Windows builds.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Here's the comparator from 1.9.1-branch code (in
nsPluginHostImpl.cpp):

static int ComparePluginFileInDirectory
  (const void *v1, const void *v2, void *)
{
  const pluginFileinDirectory* pfd1 =
    static_cast<const pluginFileinDirectory*>(v1);
  const pluginFileinDirectory* pfd2 =
    static_cast<const pluginFileinDirectory*>(v2);

  PRInt32 result = 0;
  if (LL_EQ(pfd1->mModTime, pfd2->mModTime))
    result = Compare(pfd1->mFilename, pfd2->mFilename,
                     nsCaseInsensitiveStringComparator());
  else if (LL_CMP(pfd1->mModTime, >, pfd2->mModTime))
    result = -1;
  else
    result = 1;

  return result;
}

Notice that its sense is also reversed -- it returns -1 if pfd1's
timestamp is greater than pfd2's timestamp.

Comment 3

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.