114312 - Overly zealous duplicate detection

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[tenthumbs]

Perhaps this only applies to 4.x plugins but mozilla can be too
aggressive in declaring plugins duplicates. The fixes for bug 110781
make mozilla do string comparisons. If all the strings are equal, the
plugins are duplicates. However, there seems to be no requirement that
plugin authors actually change the strings. An author could issue a
minor bug fix yet not change the description or the mime types it uses.


Consider what happens if two versions of the same plugin wind up in the
plugin directory. Mozilla searches for plugins in the directory order so
it always uses the first one it comes across. That could be the older or
the newer. There's no way to tell. Worse, once mozilla declares a plugin
a duplicate, it will always load it at startup to check. This means it
executes plugin code which can do almost anything. It's common in the
unix world to use private config files so plugins read them and perhaps
write them. One could have the situation where one version (the
""duplicate") writes to a config file at startup and the "real" version
changes it when it runs.

On Linux, file names aren't too useful but each distinct shared library
has a unique handle. I suggest that mozilla check whether handles are
the same before declaring plugins the same.

Comment 1

[av (gone)]

--- Mass reassigning Unix bugs to serge ---

Comment 2

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 3

[Josh Aas]

If this is still an issue it probably isn't one worth dealing with.