Closed
Bug 520085
Opened 15 years ago
Closed 7 years ago
Plugin priority incorrect on trunk and 1.9.2 branch (OS X and Linux)
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: smichaud, Assigned: smichaud)
Details
Attachments
(1 file)
5.11 KB,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•15 years ago
|
||
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.
Assignee: nobody → smichaud
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•15 years ago
|
||
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•7 years ago
|
||
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•