Closed Bug 313700 Opened 19 years ago Closed 13 years ago

Stale information in about:plugins (pluginreg.dat) after a plugin update


(Core Graveyard :: Plug-ins, defect)

Not set


(firefox12+ verified, firefox13 verified, firefox14 verified)

Tracking Status
firefox12 + verified
firefox13 --- verified
firefox14 --- verified


(Reporter: sfraser_bugs, Assigned: smichaud)



(Keywords: relnote, Whiteboard: [qa!])


(1 file)

When you install a new plugin on Mac, neither Firefox nor Camino display the new version of the plugin in about:plugins after quitting and restarting the application.

I have to manually delete the pluginreg.dat file from my profile before the correct plugin version information is displayed in about:plugins.

This seems like a serious user support issue.
Keywords: relnote
Which plugin?  Installed where (i.e. /Library/Internet Plug-Ins or
Contents/MacOS/plugins)?  By what means (i.e. copying by hand, or something

The Java Embedding Plugin has only very recently started changing its
about:plugins info for each new version.  So I've had only limited experience
of installing new plugins and looking for this information to change.  But I
haven't noticed any problems.

I saw this when installing Flash 8 in the default location. I've also seen it with a home-brewed plugin.
Every time a new QuickTime version comes out, we get a lot of "QT not working" posts in the Camino forum, and 99% of the time after Wevah tells them to delete the pluginreg.dat file and restart, QT starts working again.  It doesn't seem to happen to everybody (it hasn't happened to me...yet), but it happens enough.
(In reply to comment #1)
> The Java Embedding Plugin has only very recently started changing its
> about:plugins info for each new version.  So I've had only limited experience
> of installing new plugins and looking for this information to change.  But I
> haven't noticed any problems.

I just saw this after Fx software update patched my Fx nightly into the nightly that included JEP 0.9.5.  The old OJI Plugin entry was listed, as was the new JEP 0.9.5 entry.  (But I don't think Simon is implying it is the plugin's fault.)
> The old OJI Plugin entry was listed, as was the new JEP 0.9.5 entry.

Wierd.  I don't expect this would cause trouble, even if the "wrong" entry is
listed first.  But I'll keep my eyes open.  (And let me know if you see any

> (But I don't think Simon is implying it is the plugin's fault.)

No, I didn't think so.

By the way, I've now seen this problem myself, after I installed Apple's
QuickTime 7.0.3 update last night on OS X 10.4.2 -- in both Firefox and Camino
(recent nightlies), "about:plugins" still listed a "QuickTime 7.0.1" plugin
until I renamed the old files.  There weren't two listings for QuickTime,
though (I just confirmed this with copies of my old pluginreg.dat files).
On my Mac with 10.4.3, Quicktime 7.0.3 and Flash 8 I've experienced this bug. Quicktime incorrectly displayed as 7.0.2 and Flash contained duplicate entries for both version 8 and 7. This is using 20051107 Firefox 1.5 RC2 canidate build.  
Flags: blocking1.8.1?
Simon:  What exactly should we put in the relnotes? Can you put together some text and attach it to the bug so Rafael can add it to the relnotes for Firefox 1.5 (and you guys can add it to the Camino relnotes)?
I'd prefer to identify the cause first in order to write an accurate release note, but I don't have time. So I'd suggest something like:

"After installing a new plug-in, Firefox may continue to display information for the older version of the plug-in in about:plugins. If this happens, quit Firefox, delete the "pluginreg.dat" file from your profile directory, and relaunch Firefox."
*** Bug 318837 has been marked as a duplicate of this bug. ***
*** Bug 323366 has been marked as a duplicate of this bug. ***
Regarding changing the MIME types that the QT plugin handles, on Mac OS X what gets changed is ~/Library/Preferences/ and ~/Library/Preferences/QuickTime Preferences, both of which AIUI are not in the list of things that gets checked for determining if pluginreg.dat needs to regenerate itself.

That doesn't explain the caching of old versions of existing plugins, though.
I hate to say this, but most of this is probably covered in other bugs, including bug 194986, bug 236201, and bug 236195. Is there a person these plugin issues should be mentioned to?
Blocks: 236201
Plusing to keep the x-platform plugin issues on the 2.0 radar
Flags: blocking1.8.1? → blocking1.8.1+
Assignee: nobody → joshmoz
(Repeating schrep's comment from bug 236201.)
Would love to have this for the release - but since it is not a regression, top
crash, or problem with new feature taking off he blocking list for now.  JST
please re-nom once you take a look if there is a reasonable fix.
Flags: blocking1.8.1+ → blocking1.8.1-
Flags: blocking1.9?
Josh: if you think this should be a blocker, please renominate.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Summary: Firefox/Camino display stale information in about:plugins after a plugin update → Stale information in about:plugins (pluginreg.dat) after a plugin update
I see this on the branch when I tested Firefox and then updated to - I was left with the older version of the JEP.
Marcia, was the JEP in your Contents/MacOS/plugins directory (after
your update) actually JEP 0.9.5+g+2, or did
about:plugins just display the wrong version number?
Steven: On both test machines, it looks as if the JEP is actually 0.9.6 in my Contents directly, so I guess the about:plugins is reporting stale information. This only happened for me when I updated from 2001->2003 and not when I downloaded a fresh version fo 2003. 

(In reply to comment #17)
> Marcia, was the JEP in your Contents/MacOS/plugins directory (after
> your update) actually JEP 0.9.5+g+2, or did
> about:plugins just display the wrong version number?

I'm glad to hear the JEP was actually upgraded (even if its version
was reported incorrectly).

Maybe upgrades should always zap the old pluginreg.dat (and thereby
cause it to be rebuilt).  This wouldn't be a comprehensive solution
for this bug, but it'd be helpful and (I hope) easy to do.
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
I have this same problem after uninstalling quicktime and installing new 7.5 version and even uninstalling that version again. about:plugins doesn't show quicktime, but "tools -> add-ons -> plugins" says I have QuickTime Plug-in 7.1.6 installed.

Looking at my pluginreg.dat I see that it comes from my old Netscape Communicator... I don't want to remove or reinstall that program, and I;m not sure if it's safe tu just remove the pluginreg.dat as suggested in comment #0
Guess that the information wan't *that* stale...

Because the npqtplugin*.dll files still existed in my D:\Netscape\Communicator\Program\plugins directory, they were added again each time to FX3's pluginreg.dat

Don't know how FX3 finds out about thos files and why it still looks for old Netscape leftovers, but renaming/removing the files helped to get rid off the blockllisted QuickTime 7.1.6.
Assignee: joshmoz → nobody
Using the newly released Plugin Check page: Fx3.5.3 on 10.5.8/i386, it reported that I had an older version of the Flash Plugin (v10.0 r22).  about:plugins reported the same page, but Adobe's version check at , a direct check of the Flash plugin files in "/Library/Internet Plugins", and a check with Safari confirmed that I had in fact installed r32.  Deleting pluginreg.dat and restarting caused the correct version string to be used and the Plugin Check page now shows the plugin as up to date.

Once the automatic plugin check goes live, there's going to be an increase in people reporting "Mozilla says I have an old version but I know I have newest available."
I thought I had mentioned this somewhere in a bug, but maybe I just said it in #camino -- is there a particular reason, other than the minor Ts hit, we don't simply regenerate pluginreg.dat every time the browser starts? How much of a Ts hit would that be?
Hardware: PowerPC → All
One possibility is that plugin updates may not touch the top-level bundle directory (I think Smokey actually saw that happen once?), which AFAICT is the only thing that is checked when determining whether or not a plugin has changed. Checking the timestamp of the files of plugin directories makes sense on Windows and Linux, where those are binaries, but not necessarily on the Mac. We should probably be checking for the newer of (bundle timestamp, actual plugin binary timestamp).
Mossop, Unfocused: it this a problem in the Add-ons Manager? Would this affect the blocklist entry in bug 741592?
(In reply to Jorge Villalobos [:jorgev] from comment #26)
> Mossop, Unfocused: it this a problem in the Add-ons Manager? Would this
> affect the blocklist entry in bug 741592?

If the plugin code isn't spotting the plugin has been updated and loading the new information from it then yes we won't be comparing the blocklist data against the actual installed plugin.
As best I can tell, this bug only effects plugins that we bundle.  The bug happens when we use the Firefox update infrastructure to update the bundled plugin -- that mechanism doesn't delete the old pluginreg.dat file.

I don't think we currently bundle *any* plugins -- I believe the JEP was the last.
Other kinds of addons (like extensions) don't use pluginreg.dat.

Though if we updated bundled extensions, that might conceivably cause the same problem.
We've seen this happening on Mac OS X with the Java plugin. Updating to the latest version didn't update the metadata in about:plugins or about:addons. Deleting pluginreg.dat fixes that, which is why I assumed it was related to this bug.
(Following up comment #28)

> As best I can tell, this bug only effects plugins that we bundle.

Oops, this is wrong.  The bug happens whenever a plugin is updated without changing the date of the subdirectory of the plugins directory where Firefox finds it.

For example /Library/Internet Plug-Ins/Flash Player.plugin, or (in a 1.9.2-branch Mac distro) Contents/MacOS/plugins/MRJPlugin.plugin.

(In reply to comment #30)

Yes, it probably is related.  For the last couple of years, the Java plugin's "entry" in /Library/Internet Plug-Ins/ has been a soft link, whose date probably wouldn't change if its target changed.
Blocks: 742702
I'm going to see what I can accomplish here.
Assignee: nobody → smichaud
Attached patch Possible fixSplinter Review
Here's a fix for the problem of a plugin's top-level directory (its
package directory) not getting "touched" when the plugin itself is

It's very simple, and should be low-risk.

It's also what we should have been doing all along:  It makes much
more sense to check the last-modified date of a	bundle's Info.plist
file than of its package directory.  A bundle's	Info.plist file	will
always get changed when	the bundle's version changes (since that's
where the version information is stored).

The little testing I've done suggests this patch should allow us to
finish work on bug 742702.  But I haven't tested updating Apple's Java
plugin, since that's such an incredible pain:  Apple's Java updates
can't be uninstalled.  So re-doing a test of a Java update requires
first doing a clean re-install of the OS :-(

I *have* done the following, which always "worked":

1) "touch" a plugin's Info.plist file (which sometimes requires using

2) Run FF with my patch, then go to "Tools : Add Ons".

3) Check whether pluginreg.dat has been updated.

   In my tests it always did get updated.  It didn't get updated if I
   skipped step 1.

I've started tryserver builds, which should be available in a few
Attachment #613403 - Flags: review?(joshmoz)
(Following up comment #33)

I also ran the same test with today's mozilla-central nightly.

It always "fails".  "touch"ing a plugin's Info.plist file never changes the date of its package directory or of its Contents directory.  Which means that, in current code, pluginreg.dat doesn't get updated when it should be.
Comment on attachment 613403 [details] [diff] [review]
Possible fix

Review of attachment 613403 [details] [diff] [review]:

::: xpcom/io/nsLocalFileUnix.cpp
@@ +2443,5 @@
> +nsLocalFile::GetBundleContentsLastModifiedTime(PRInt64 *aLastModTime)
> +{
> +  CHECK_mPath();
> +  NS_ENSURE_ARG(aLastModTime);

I'd prefer NS_ENSURE_ARG_POINTER here. Functionally the same thing but more future-proof.
Attachment #613403 - Flags: review?(joshmoz) → review+
Comment on attachment 613403 [details] [diff] [review]
Possible fix

Landed on mozilla-inbound with Josh's suggested change:

I don't know whether or not this patch needs sr.  Though I've landed it anyway because it's so urgent.

It does change an interface (nsILocalFileMac).  But this interface is (basically) private, and very unlikely to be used by web content.

If people think I should ask for sr, I'll do it retrospectively.
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
(In reply to Steven Michaud from comment #35)
> Here's a tryserver build made with my patch from comment #33:
> 49abed576001/try-macosx64/firefox-14.0a1.en-US.mac.dmg

Just tried this build with my affected profile on 10.7 - it did the trick and showed the latest version of Java! I think we just want to test to make sure that when Java is updated after using this build, we still update pluginreg.dat.
Done all that but still no joy, both the GUI and command-line (my preferred environment) methods. I'm on Mac OS X Lion Server 10.7.3. Java is up-to-date but Firefox 11.0 still continues to report insecure version of Java.

$ java -version java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04-413-11M3623) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-413, mixed mode)

See screen shot of various versions at:
Fred, is the version of Java that you actually have being reported as insecure?

If so, then what you're seeing isn't this bug.

This bug is about FF not detecting the new version when a plugin (like the Java plugin) has been updated.
Also, this bug's fix hasn't yet gotten into any FF release, and certainly not into FF 11 (which was released a while ago).
I'm using Java 1.6.0_31 but Firefox sees it as 1.6.0_29. So it thinks it is the earlier, insecure version.  

I wanted to report this, as some people are saying that deleting pluginreg.dat fixes the problem. That isn't working for me.

Here's an excerpt from pluginreg.dat. Notice the next to last line, where it is showing the incorrect Java version:

Displays Java applet content, or a placeholder if Java is not installed.:$
Java Applet Plug-in:$
0:application/x-java-applet;version=1.1.3:Java applet::$
1:application/x-java-applet:Basic Java Applets:javaapplet:$
2:application/x-java-applet;version=1.2.2:Java applet::$
3:application/x-java-applet;version=1.5:Java applet::$
4:application/x-java-vm:Java applet::$
5:application/x-java-applet;version=1.3.1:Java applet::$
6:application/x-java-applet;version=1.3:Java applet::$
7:application/x-java-applet;version=1.1.2:Java applet::$
8:application/x-java-applet;version=1.1:Java applet::$
9:application/x-java-applet;version=1.2.1:Java applet::$
10:application/x-java-applet;version=1.6:Java applet::$
11:application/x-java-applet;version=1.4.2:Java applet::$
12:application/x-java-applet;version=1.4:Java applet::$
13:application/x-java-applet;version=1.1.1:Java applet::$
14:application/x-java-applet;version=1.2:Java applet::$
15:application/x-java-applet;jpi-version=1.6.0_29:Java applet::$
Fred, I suspect you have more than one profile, and are deleting pluginreg.dat from the "wrong" one.
No, in Firefox I type "about:support" and then click the "show profile" button to open my profile folder in Finder. Or from the command-line, I know my way around, I run servers for a living, managing them via ssh.

Besides, I only have one profile. This is a fairly new computer, and I did a new installation on it. I'm familiar with profile management, and have created multiple profiles in the past on my previous machine, but not this one.

I would love it if this worked.

I just tried on my Macbook running Lion (not Server) 10.7.3 and it is also doing the same thing - reporting Java as insecure, even though I have the latest.
Okay, so what I'm trying to highlight is that Firefox is detecting the wrong version of Java.  Then the plug-in checker reports that it is insecure. 1.6.0_29 was insecure, but I am running 1.6.0_31.  You can see in pluginreg.dat that it thinks I'm running 1.6.0_29, but in reality I am running 1.6.0_31.  Java Preferences panel also confirms this.  It shows 1.6.0_31 for both 32-bit and 64-bit java.
Fred, the problem you see isn't this bug.  Please open another one.

Another thing to look out for is multiple copies of the Java plugin.   That's highly unlikely.  But if you only have one profile, that's the only other explanation I can think of.
Okay, I may open another bug report. I ran /usr/libexec/java_home and went to the folder where it pointed. I only see one Java in there.


Fred: Just to close this out, as I'm not sure you opened a new bug, Apple's initial release of U31 had a bug where the jp-version in the plugin's plist file (which is what we use for plugincheck version detection) wasn't updated to
1.6.0_31 in

Apple has since pushed another version, and you should re-check software update.

(In reply to Fred Laxton from comment #48)
> Okay, I may open another bug report. I ran /usr/libexec/java_home and went
> to the folder where it pointed. I only see one Java in there.
> Thanks!
> Fred
I agree, Apple messed up.  I did not open a new bug report. I just today saw another Software Update "Java for OS X 2012-002" to Java from Apple. In the description it says it upgrades to 1.6.0_31! Even though I had *already* installed "Java for OS X 2012-001" which went to 1.6.0_31, supposedly.

I installed and now Firefox is happy. Case closed ;-)
I'm also very happy to see "Java for OS X 2012-002", but for a different reason.  Installing it allowed me to test this bug's patch (in today's mozilla-central nightly) without having to first do a clean reinstall of OS X 10.7.

My patch passed the test!

I ran today's mozilla-central nightly before installing Apple's update and did about:config -- the wrong Java version was reported.  Then I quit the nightly and ran Apple's updater.  Then I restarted the nightly and again did about:plugins.  This time pluginreg.dat got updated, and the correct Java version was reported.
Comment on attachment 613403 [details] [diff] [review]
Possible fix

On the strength of what I report in comment #51, I'm requesting approval to land on aurora and beta.

My patch is low risk and fixes an urgent, very serious problem:  It allows us to blocklist older versions of Java on the Mac that have a security hole that's being actively exploited.

I'd like to land my patch on both branches as soon as possible.  Hopefully sometime today, to miss tomorrow's last-minute rush :-)
Attachment #613403 - Flags: approval-mozilla-beta?
Attachment #613403 - Flags: approval-mozilla-aurora?
Comment on attachment 613403 [details] [diff] [review]
Possible fix

[Triage Comment]
Thanks for testing, Steven! Approving for both Aurora 13 and Beta 12.
Attachment #613403 - Flags: approval-mozilla-beta?
Attachment #613403 - Flags: approval-mozilla-beta+
Attachment #613403 - Flags: approval-mozilla-aurora?
Attachment #613403 - Flags: approval-mozilla-aurora+
We should presumably do something about this in our ESR release, too.
Interestingly, Apple's now made available a "Java for OS X 2012-003" update for OS X 10.7.

I don't know why.  But I suspect it has something to do with the following weirdness I noticed with the 002 update:

When you double-click on 002, you're warned that "there may be a problem with this disk image", and are asked if you want to open it (with "Don't Open" being the default).

In fact I don't think anything's seriously wrong with the 002 image -- hdiutil verify doesn't report any problems with it.  I'd guess it might have been signed incorrectly.
(In reply to Steven Michaud from comment #55)
> We should presumably do something about this in our ESR release, too.

Agreed - we'll want this on the ESR branch as well.
(Following up comment #56)

Actually, Apple's description explains it.  Update 003 does more than just fix the Java bug:

This Java security update removes the most common variants of the Flashback malware.

This update also configures the Java web plug-in to disable the automatic execution of Java applets. Users may re-enable automatic execution of Java applets using the Java Preferences application. If the Java web plug-in detects that no applets have been run for an extended period of time it will again disable Java applets.
Attachment #613403 - Flags: approval-mozilla-esr10?
Comment on attachment 613403 [details] [diff] [review]
Possible fix

[Triage Comment]
Approved for landing on ESR, please refer to
Attachment #613403 - Flags: approval-mozilla-esr10? → approval-mozilla-esr10+
Whiteboard: [qa+]
I've verified this on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.4esrpre) Gecko/20120416 Firefox/10.0.4esrpre

First, I've performed a clean install of an older version of Flash (flash10_1r102_64) and after restart, the Flash version was listed in Add-ons Manager and also in about:plugins.

Then I've updated to the latest flash version which was also listed after restart in Add-ons Manager and also about:plugins.
IMO, this bug is verified fixed on 10.0.4esrpre.
I've verified this on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0 beta 6

using the steps from comment61.
Both versions of Flash are listed properly.

Considering this, changing the flag to verified on both ESR and also Beta.
Verified on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0 beta 4 

using the steps from comment61. Both versions of flash are listed properly.
Verified on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20100101 Firefox/14.0 beta 6 (build2)

Like before, both versions of flash are listed properly.

Changing the status of the bug to Verified Fixed.
Whiteboard: [qa+] → [qa!]
I hate to report that I've been consistently finding this same issue in my current installation, and same has been happening to me for a while:
Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0

Every time I have an updated Flash version, I need to erase pluginreg.dat for Firefox to acknowledge the new version.
I agree.  Fedora 23 thru 25. Have to remove pluginreg.dat to get Firefox to acknowledge the new version.

This bug still exists. It should not be listed as fixed.

Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.