Last Comment Bug 313700 - Stale information in about:plugins (pluginreg.dat) after a plugin update
: Stale information in about:plugins (pluginreg.dat) after a plugin update
Status: VERIFIED FIXED
[qa!]
: relnote
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All Mac OS X
: -- normal with 2 votes (vote)
: mozilla14
Assigned To: Steven Michaud [:smichaud] (Retired)
:
Mentors:
: 318837 323366 565158 (view as bug list)
Depends on:
Blocks: 236201 596135 741592 742702
  Show dependency treegraph
 
Reported: 2005-10-24 22:39 PDT by Simon Fraser
Modified: 2014-11-10 01:58 PST (History)
35 users (show)
jonas: blocking1.9-
reed: wanted1.9+
dbaron: blocking1.8.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
verified
verified
verified


Attachments
Possible fix (5.05 KB, patch)
2012-04-09 14:53 PDT, Steven Michaud [:smichaud] (Retired)
jaas: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
lukasblakk+bugs: approval‑mozilla‑esr10+
Details | Diff | Splinter Review

Description Simon Fraser 2005-10-24 22:39:39 PDT
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.
Comment 1 Steven Michaud [:smichaud] (Retired) 2005-10-25 14:00:46 PDT
Which plugin?  Installed where (i.e. /Library/Internet Plug-Ins or
Contents/MacOS/plugins)?  By what means (i.e. copying by hand, or something
else)?

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.

Comment 2 Simon Fraser 2005-10-25 18:13:38 PDT
I saw this when installing Flash 8 in the default location. I've also seen it with a home-brewed plugin.
Comment 3 Smokey Ardisson (offline for a while; not following bugs - do not email) 2005-10-26 00:35:16 PDT
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.
Comment 4 Smokey Ardisson (offline for a while; not following bugs - do not email) 2005-10-27 06:19:15 PDT
(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.)
Comment 5 Steven Michaud [:smichaud] (Retired) 2005-10-27 11:48:08 PDT
> 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
trouble.)

> (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).
Comment 6 Jim Durkin 2005-11-09 23:43:36 PST
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.  
Comment 7 Jay Patel [:jay] 2005-11-28 15:56:38 PST
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)?
Comment 8 Simon Fraser 2005-11-28 20:03:53 PST
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."
Comment 9 Smokey Ardisson (offline for a while; not following bugs - do not email) 2005-12-02 20:12:34 PST
*** Bug 318837 has been marked as a duplicate of this bug. ***
Comment 10 Smokey Ardisson (offline for a while; not following bugs - do not email) 2006-01-13 21:41:27 PST
*** Bug 323366 has been marked as a duplicate of this bug. ***
Comment 11 Smokey Ardisson (offline for a while; not following bugs - do not email) 2006-01-13 22:29:22 PST
Regarding changing the MIME types that the QT plugin handles, on Mac OS X what gets changed is ~/Library/Preferences/com.apple.quicktime.plugin.preferences.plist 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.
Comment 12 Samuel Sidler (old account; do not CC) 2006-01-13 22:39:47 PST
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?
Comment 13 Mike Schroepfer 2006-06-16 18:46:03 PDT
Plusing to keep the x-platform plugin issues on the 2.0 radar
Comment 14 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-06-28 18:55:00 PDT
(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.
Comment 15 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-02-15 16:53:55 PST
Josh: if you think this should be a blocker, please renominate.
Comment 16 Marcia Knous [:marcia - use ni] 2007-03-21 13:34:41 PDT
I see this on the branch when I tested Firefox 2.0.0.1 and then updated to 2.0.0.3 - I was left with the older version of the JEP.
Comment 17 Steven Michaud [:smichaud] (Retired) 2007-03-21 13:55:38 PDT
Marcia, was the JEP in your Contents/MacOS/plugins directory (after
your 2.0.0.1-2.0.0.3 update) actually JEP 0.9.5+g+2, or did
about:plugins just display the wrong version number?
Comment 18 Marcia Knous [:marcia - use ni] 2007-03-21 14:55:55 PDT
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 2.0.0.1-2.0.0.3 update) actually JEP 0.9.5+g+2, or did
> about:plugins just display the wrong version number?
> 

Comment 19 Steven Michaud [:smichaud] (Retired) 2007-03-22 10:20:38 PDT
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.
Comment 20 Onno Ekker [:nONoNonO UTC+1] 2008-08-06 02:12:01 PDT
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
Comment 21 Onno Ekker [:nONoNonO UTC+1] 2008-08-06 02:28:56 PDT
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.
Comment 22 Hanspeter Niederstrasser 2009-10-14 11:22:57 PDT
Using the newly released Plugin Check page: http://www.mozilla.com/en-US/plugincheck/ 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 http://www.adobe.com/software/flash/about/ , 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."
Comment 23 Chris Lawson (gone) 2009-10-14 14:15:48 PDT
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?
Comment 24 Smokey Ardisson (offline for a while; not following bugs - do not email) 2010-05-11 21:58:25 PDT
*** Bug 565158 has been marked as a duplicate of this bug. ***
Comment 25 Stuart Morgan 2011-01-14 17:20:25 PST
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).
Comment 26 Jorge Villalobos [:jorgev] 2012-04-04 13:58:28 PDT
Mossop, Unfocused: it this a problem in the Add-ons Manager? Would this affect the blocklist entry in bug 741592?
Comment 27 Dave Townsend [:mossop] 2012-04-04 14:03:29 PDT
(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.
Comment 28 Steven Michaud [:smichaud] (Retired) 2012-04-04 14:49:11 PDT
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.
Comment 29 Steven Michaud [:smichaud] (Retired) 2012-04-04 14:50:41 PDT
Other kinds of addons (like extensions) don't use pluginreg.dat.

Though if we updated bundled extensions, that might conceivably cause the same problem.
Comment 30 Jorge Villalobos [:jorgev] 2012-04-04 14:52:29 PDT
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.
Comment 31 Steven Michaud [:smichaud] (Retired) 2012-04-04 15:06:06 PDT
(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.
Comment 32 Steven Michaud [:smichaud] (Retired) 2012-04-09 08:18:32 PDT
I'm going to see what I can accomplish here.
Comment 33 Steven Michaud [:smichaud] (Retired) 2012-04-09 14:53:24 PDT
Created attachment 613403 [details] [diff] [review]
Possible fix

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
updated.

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
   sudo).

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
hours.
Comment 34 Steven Michaud [:smichaud] (Retired) 2012-04-09 15:55:13 PDT
(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 35 Steven Michaud [:smichaud] (Retired) 2012-04-09 18:43:06 PDT
Here's a tryserver build made with my patch from comment #33:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-49abed576001/try-macosx64/firefox-14.0a1.en-US.mac.dmg
Comment 36 Josh Aas 2012-04-10 05:59:00 PDT
Comment on attachment 613403 [details] [diff] [review]
Possible fix

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

::: xpcom/io/nsLocalFileUnix.cpp
@@ +2443,5 @@
> +NS_IMETHODIMP
> +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.
Comment 37 Steven Michaud [:smichaud] (Retired) 2012-04-10 09:02:35 PDT
Comment on attachment 613403 [details] [diff] [review]
Possible fix

Landed on mozilla-inbound with Josh's suggested change:
http://hg.mozilla.org/integration/mozilla-inbound/rev/95a886a80f9b

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.
Comment 38 Matt Brubeck (:mbrubeck) 2012-04-11 09:02:55 PDT
https://hg.mozilla.org/mozilla-central/rev/95a886a80f9b
Comment 39 Alex Keybl [:akeybl] 2012-04-11 10:05:03 PDT
(In reply to Steven Michaud from comment #35)
> Here's a tryserver build made with my patch from comment #33:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-
> 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.
Comment 40 Fred Laxton 2012-04-11 10:25:19 PDT
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: 
https://support.mozilla.org/media/uploads/images/2012-04-11-10-16-50-fda07f.png
Comment 41 Steven Michaud [:smichaud] (Retired) 2012-04-11 10:49:04 PDT
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.
Comment 42 Steven Michaud [:smichaud] (Retired) 2012-04-11 10:50:54 PDT
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).
Comment 43 Fred Laxton 2012-04-11 13:08:35 PDT
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:

JavaAppletPlugin.plugin:$
/System/Library/Java/Support/CoreDeploy.bundle/Contents/JavaAppletPlugin.plugin:$
14.2.0:$
1308051513000:0:1:$
Displays Java applet content, or a placeholder if Java is not installed.:$
Java Applet Plug-in:$
17
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::$
16:application/x-java-vm-npruntime:::$
Comment 44 Steven Michaud [:smichaud] (Retired) 2012-04-11 13:12:30 PDT
Fred, I suspect you have more than one profile, and are deleting pluginreg.dat from the "wrong" one.
Comment 45 Fred Laxton 2012-04-11 13:23:17 PDT
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.
Comment 46 Fred Laxton 2012-04-11 13:26:25 PDT
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.
Comment 47 Steven Michaud [:smichaud] (Retired) 2012-04-11 13:42:22 PDT
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.
Comment 48 Fred Laxton 2012-04-11 13:49:32 PDT
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
Comment 49 Kev Needham [:kev] 2012-04-12 07:24:37 PDT
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
/System/Library/Java/Support/CoreDeploy.bundle/Contents/JavaAppletPlugin.plugin/Contents/Info.plist

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
Comment 50 Fred Laxton 2012-04-12 09:27:06 PDT
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 ;-)
Comment 51 Steven Michaud [:smichaud] (Retired) 2012-04-12 09:46:45 PDT
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 52 Steven Michaud [:smichaud] (Retired) 2012-04-12 09:51:48 PDT
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 :-)
Comment 53 Alex Keybl [:akeybl] 2012-04-12 10:26:11 PDT
Comment on attachment 613403 [details] [diff] [review]
Possible fix

[Triage Comment]
Thanks for testing, Steven! Approving for both Aurora 13 and Beta 12.
Comment 54 Steven Michaud [:smichaud] (Retired) 2012-04-12 12:13:03 PDT
Comment on attachment 613403 [details] [diff] [review]
Possible fix

Landed on aurora and beta:
http://hg.mozilla.org/releases/mozilla-aurora/rev/ad0bb5f6080f
http://hg.mozilla.org/releases/mozilla-beta/rev/cf0b048b22ee
Comment 55 Steven Michaud [:smichaud] (Retired) 2012-04-12 12:14:23 PDT
We should presumably do something about this in our ESR release, too.
Comment 56 Steven Michaud [:smichaud] (Retired) 2012-04-12 16:11:19 PDT
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.
Comment 57 Alex Keybl [:akeybl] 2012-04-12 16:12:50 PDT
(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.
Comment 58 Steven Michaud [:smichaud] (Retired) 2012-04-12 16:16:07 PDT
(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.
Comment 59 Lukas Blakk [:lsblakk] use ?needinfo 2012-04-13 15:06:19 PDT
Comment on attachment 613403 [details] [diff] [review]
Possible fix

[Triage Comment]
Approved for landing on ESR, please refer to https://wiki.mozilla.org/Release_Management/ESR_Landing_Process
Comment 60 Steven Michaud [:smichaud] (Retired) 2012-04-13 16:24:57 PDT
Comment on attachment 613403 [details] [diff] [review]
Possible fix

Landed on the esr10 branch:
https://hg.mozilla.org/releases/mozilla-esr10/rev/1a43341e99df
Comment 61 Vlad [QA] 2012-04-17 06:48:49 PDT
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.
Comment 62 Vlad [QA] 2012-04-20 06:35:31 PDT
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.
Comment 63 Vlad [QA] 2012-05-18 07:07:56 PDT
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.
Comment 64 Vlad [QA] 2012-06-12 02:40:40 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.