Last Comment Bug 686335 - Bad plugin search order prevents upgrading Flash without an OS restart
: Bad plugin search order prevents upgrading Flash without an OS restart
Status: RESOLVED FIXED
: sec-moderate
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: x86 Windows XP
: -- normal with 1 vote (vote)
: mozilla17
Assigned To: Josh Aas
:
Mentors:
: 754293 (view as bug list)
Depends on: 642807 768383 769580 776923
Blocks: 751826 767612
  Show dependency treegraph
 
Reported: 2011-09-12 11:36 PDT by John Pfeiffer
Modified: 2013-12-27 14:31 PST (History)
27 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
wontfix
+
wontfix
+
wontfix
+
wontfix


Attachments
Reverse scan order of the Plugins array in ScanPluginsDirectory. (1.08 KB, patch)
2012-05-16 15:02 PDT, Stephen A Pohl [:spohl]
no flags Details | Diff | Review
Patch that allows to reload and use updated Plugins in a running browser session. (8.50 KB, patch)
2012-05-19 01:44 PDT, Stephen A Pohl [:spohl]
no flags Details | Diff | Review
fix v0.5 (14.95 KB, patch)
2012-05-28 20:08 PDT, Josh Aas
no flags Details | Diff | Review
fix v1.0 (21.87 KB, patch)
2012-06-07 14:02 PDT, Josh Aas
no flags Details | Diff | Review
fix v1.1 (21.81 KB, patch)
2012-06-07 15:07 PDT, Josh Aas
benjamin: review+
Details | Diff | Review
fix v1.1 (23.23 KB, patch)
2012-06-13 09:55 PDT, Josh Aas
benjamin: review+
Details | Diff | Review
fix v1.2 (23.21 KB, patch)
2012-06-13 15:43 PDT, Josh Aas
akeybl: approval‑mozilla‑release-
Details | Diff | Review
Backout changes from Aurora completely. (19.90 KB, patch)
2012-07-19 15:03 PDT, Georg Fritzsche [:gfritzsche] [away Jun 24 - Jul 3]
no flags Details | Diff | Review
Reapply bookkeeping fix only to Aurora. (1.51 KB, patch)
2012-07-19 15:04 PDT, Georg Fritzsche [:gfritzsche] [away Jun 24 - Jul 3]
no flags Details | Diff | Review

Description John Pfeiffer 2011-09-12 11:36:24 PDT
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.9
Build ID: 20110420140830

Steps to reproduce:

We are attempting to upgrade our Plugin when the Plugin is in use. Here is how we are attempting to do this:
1. Install a newer version of our Plugin next to the old Plugin (using a slightly different filename).
2. Update the full pathname to our Plugin in HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\
3. Call navigator.plugins.refresh() from C++ or from a web page.


Actual results:

The plugins array still references the old Plugin.


Expected results:

The plugins array should reference the new Plugin.
Comment 1 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-09-12 21:20:23 PDT
Are you passing true or false to refresh()?  If you're passing false, then in-use plugins won't be unloaded, for obvious reasons...
Comment 2 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-09-12 21:21:16 PDT
Oh, and the argument is optional and the default value is false, so if you're just passing nothing you're saying you do NOT want to mess with already-running plugins.
Comment 3 Stephen A Pohl [:spohl] 2011-09-12 22:21:48 PDT
All three options don't appear to work:
1. navigator.plugins.refresh()
2. navigator.plugins.refresh(false)
3. navigator.plugins.refresh(true)

The pluginreg.dat appears to never be touched, and no new plugins are loaded.

Sample JS code:
<html>
<head>
    <script type="text/javascript">
        function UpdatePlugins() {
            if (navigator.plugins) {
                navigator.plugins.refresh();
                alert ("The plugins collection has been updated!");
            }
            else {
                alert ("Browser does not support navigator.plugins!");
            }
        }
    </script>
</head>
<body>
    <button onclick="UpdatePlugins();">Update plugins!</button>
</body>
</html>
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-09-12 22:28:14 PDT
Hmm... that's odd.  The code certainly looks like it should work when true is passed.

Josh, any idea what's up here?
Comment 5 Josh Aas 2011-09-13 08:09:38 PDT
I have an idea, need to confirm. I can try to do that this evening.
Comment 6 Stephen A Pohl [:spohl] 2011-09-14 21:00:51 PDT
NPN_ReloadPlugins() seems like it could do the trick too. Unfortunately, it does not appear to work either.
Comment 7 Jet Villegas (:jet) 2011-10-14 12:06:47 PDT
::ScanPluginsDirectory() appears to only flag that aPluginsChanged==true if the plug-in existed at startup. This is not the case when Flash adds a new binary while FF is already running. I think we can fix this by adding an else case to flag that aPluginsChanged=true when we encounter a brand-new binary in the folder.
Comment 8 Jet Villegas (:jet) 2011-10-14 13:13:35 PDT
It also looks like NS_PLUGIN_FLAG_UNWANTED is getting set on the new binary as the Equals() check sees the same name/description/mime types as the existing Flash Player.
Comment 9 Stephen A Pohl [:spohl] 2011-10-21 12:50:51 PDT
Jet helped us isolate the problem. By modifying the ProductName and the Description key in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins) between versions, for example by adding the version number, we were able to get the refresh of the plugins array to work successfully. Changing only the Version key was not enough.

Some helpful info:
https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-in_Development_Overview
Comment 10 Jet Villegas (:jet) 2011-10-21 12:56:55 PDT
Fixed on the Flash side by Stephen A. Pohl. Closing.
Comment 11 Stephen A Pohl [:spohl] 2012-05-11 10:03:19 PDT
Unfortunately, this still appears to be a problem. One of our customers has been investigating this further and made the following statement:

"This is extremely easy to replicate.  I went into the

c:\windows\system32\macromed\flash

directory and copied NPSWF32_11_2_202_235.dll to NPSWF32_11_2_202_233.dll

 

I then launched ProcMon from SysInternals so I could spy on exactly what was happening.  Then I launched Firefox and went to the adobe flash about page.  Of course, it returned version 235.  But ProcMon told a different story.  Firefox had launched the plugin-container.exe using the 233 DLL I just copied!

"C:\Program Files\Mozilla Firefox\plugin-container.exe" --channel=2500.56b6a60.744882939 "C:\WINDOWS\system32\Macromed\Flash\NPSWF32_11_2_202_233.dll" - -greomni "C:\Program Files\Mozilla Firefox\omni.ja" 2500 "\\.\pipe\gecko-crash-server-pipe.2500" plugin

 

The problem comes because Firefox is using a QueryDirectory command with '*' when it looks in the Macromed\Flash directory for the DLL.  This returns items alphabetically.  It must be looking for the NPSWF32 prefix, so the LOWEST version number will always win!

 

To prove this, I made a copy of NPSWF32_11_2_202_235.dll and named it NPSWF32_0.dll.  So now I'm looking at the following directory entries.

 

FlashInstall.log

flashplayer.xpt

FlashPlayerUpdateService.exe

FlashUtil32_11_2_202_235_Plugin.exe

mms.cfg

NPSWF32_0.dll

NPSWF32_11_2_202_235.dll

 

Note that alphabetically, my _0 copy is above the real copy.  I use ProcMon to spy on Firefox once again.  And Firefox goes and loads NPSW32_0.dll into the plugin-container.exe command line!  This is despite the registry having no mention of this file, and all registry entries that refer to flash have NPSWF32_11_2_202_235.dll in them."
Comment 12 Stephen A Pohl [:spohl] 2012-05-11 10:06:09 PDT
At this point, Mozilla Firefox is the only major browser that requires a system restart to load the new Flash Player. This is due to the fact that old Flash Player binaries are marked for delete upon reboot. Only then will Firefox start loading the latest Flash Player.

Please let us know if we can be of further assistance to get this resolved.
Comment 13 Matthias Versen [:Matti] 2012-05-11 10:09:27 PDT
*** Bug 754293 has been marked as a duplicate of this bug. ***
Comment 14 Benjamin Smedberg [:bsmedberg] 2012-05-11 11:34:02 PDT
So as far as I know, we shouldn't be searching any directories for Flash: we should be using whatever is in the registry. So in my registry, I have:

HKLM Software Wow6432Node MozillaPlugins @adobe.com/FlashPlayer
  Path: C:\Windows\SysWOW64\Macromed\Flash\NPSWF32.dll

There has never been, AFAICT, numbered versions of the Flash Player DLL. And in any case I don't know of any current code which goes poking through directory entries for the Flash Player DLL (other than perhaps in the Firefox plugins/ subdirectory, but that shouldn't apply to this case at all).
Comment 15 Stephen A Pohl [:spohl] 2012-05-11 11:37:09 PDT
> There has never been, AFAICT, numbered versions of the Flash Player DLL.

Numbered version names for the Flash Player DLL were introduced with Flash Player 11.2 to enable updates to occur even if the DLL is currently in use.
Comment 16 Stephen A Pohl [:spohl] 2012-05-15 23:14:22 PDT
The problem at a general level appears to be that Firefox is checking for an updated Plugin based on the "last modified" date of a DLL. On Windows, a DLL is locked when in use and cannot be replaced. Therefore, the only way to install an updated Plugin while the old DLL is loaded is to install it with a different file name. This leads to problems in ScanPluginsDirectory, since two identical Plugins will be found (based on MimeType etc.).

This is a partial call stack that illustrates this problem:
>	xul.dll!nsPluginHost::IsDuplicatePlugin(nsPluginTag * aPluginTag) Line 1910	C++
 	xul.dll!nsPluginHost::ScanPluginsDirectory(nsIFile * pluginsDir, bool aCreatePluginList, bool * aPluginsChanged) Line 2108	C++
 	xul.dll!nsPluginHost::ScanPluginsDirectoryList(nsISimpleEnumerator * dirEnum, bool aCreatePluginList, bool * aPluginsChanged) Line 2205	C++
 	xul.dll!nsPluginHost::FindPlugins(bool aCreatePluginList, bool * aPluginsChanged) Line 2318	C++
 	xul.dll!nsPluginHost::LoadPlugins() Line 2232	C++
 	xul.dll!nsPluginHost::ReloadPlugins(bool reloadPages) Line 509	C++
 	xul.dll!nsPluginArray::Refresh(bool aReloadDocuments) Line 223	C++

IsDuplicatePlugin will return true for the updated version of the DLL if it is being scanned after the old plugin was already found. The updated version of the plugin will now be marked with NS_PLUGIN_FLAG_UNWANTED and the old Plugin will be used by Firefox instead.

Ideally, Firefox would reload Plugins on Windows based on the registry. If this isn't possible as a general rule for all Plugins, we might want to check against the registry if duplicate Plugins are found (in IsDuplicatePlugin). This would ensure that the correct and most up-to-date Plugin is being loaded.
Comment 17 Stephen A Pohl [:spohl] 2012-05-16 13:36:10 PDT
With a one line change, Firefox could start loading the new Plugin after a browser restart (as opposed to a system reboot currently).

Changing the for loop in ScanPluginsDirectory from:

> for (PRUint32 i = 0; i < pluginFiles.Length(); i++)

to:

> for (PRInt32 i = pluginFiles.Length() - 1; i >= 0; i--)

would allow Firefox to load the new Plugin after a browser restart. Iterating from the back of the array to the front would first detect the alphabetically last Plugin (the most up-to-date one in the case of Flash Player) and mark any duplicate Plugins as unwanted. There doesn't seem to be a rule as to which duplicate plugin should be marked as unwanted, so this might be a workaround until a more thorough implementation (by checking the registry etc.) could be submitted.

Even with this change though, an open browser session will continue to use the old Plugin. A browser restart will still be necessary.
Comment 18 Stephen A Pohl [:spohl] 2012-05-16 15:02:30 PDT
Created attachment 624554 [details] [diff] [review]
Reverse scan order of the Plugins array in ScanPluginsDirectory.
Comment 19 Stephen A Pohl [:spohl] 2012-05-17 11:03:44 PDT
This issue seems to have various "fixed states":
1. System restart to load the new version of a Plugin is acceptable
2. Browser restart to load the new version of a Plugin is acceptable, system restart is not.
3. Launching a new tab to load the new version of a Plugin is acceptable, system or browser restart is not.

Patch #624554 moved us from state 1 to state 2 and we no longer require a system restart. I'm still exploring a few ways to reach state 3 without incurring the cost of major changes that need extensive testing.

We currently still need to restart the browser because the browser generates a cache of Plugins when it is started. If we install while the browser is running, the new Plugin will be detected as duplicate of a Plugin in the cache and marked as unwanted. If we restart the browser, the cache of Plugins will be regenerated and because of the reversed search order in patch #624554, the browser will now pick up the new version first and mark the old version as duplicate, i.e. unwanted.
Comment 20 Asa Dotzler [:asa] 2012-05-18 17:13:30 PDT
Does this affect all Firefox versions? If so, we might want to try to roll out a fix sooner than Firefox 15.
Comment 21 Stephen A Pohl [:spohl] 2012-05-19 01:44:31 PDT
Created attachment 625377 [details] [diff] [review]
Patch that allows to reload and use updated Plugins in a running browser session.

This is expanding (and including) my previous patch, but now allows to reload and use plugins in a running browser session. The only requirement is that a Plugin detects that it was updated and calls ReloadPlugins().
Comment 22 Sheila Mooney 2012-05-21 10:17:33 PDT
We want to get this in sooner rather than later. We don't need it for the softblock of Flash but if we do the fill block we will need it. Having it fixed in the build enables us to implement the full block if we run into a case where it's absolutely necessary.
Comment 23 Alex Keybl [:akeybl] 2012-05-21 10:21:48 PDT
(In reply to Sheila Mooney from comment #22)
> We want to get this in sooner rather than later. We don't need it for the
> softblock of Flash but if we do the fill block we will need it. Having it
> fixed in the build enables us to implement the full block if we run into a
> case where it's absolutely necessary.

There are no plans to soft/hard block Flash before we update the blocklist UX, so I don't think this needs to be tracked for any version earlier than FF15 (if even that).
Comment 24 Stephen A Pohl [:spohl] 2012-05-21 10:28:05 PDT
I might be pointing out the obvious (apologies if I do): As far as we can tell, this is an issue that Firefox users are currently running into with all versions of Firefox. See comment 12:

> At this point, Mozilla Firefox is the only major browser that requires a
> system restart to load the new Flash Player. This is due to the fact that
> old Flash Player binaries are marked for delete upon reboot. Only then will 
> Firefox start loading the latest Flash Player.
Comment 25 [On PTO until 6/29] 2012-05-21 12:54:16 PDT
(In reply to Alex Keybl [:akeybl] from comment #23)
> There are no plans to soft/hard block Flash before we update the blocklist
> UX, so I don't think this needs to be tracked for any version earlier than
> FF15 (if even that).

Well, originally, we were talking about doing some sort of blocking for year old versions of Flash in the immediate future. Is that now off the table? I haven't seen that clearly stated elsewhere.
Comment 26 Alex Keybl [:akeybl] 2012-05-21 13:37:02 PDT
(In reply to Al Billings [:abillings] from comment #25)
> Well, originally, we were talking about doing some sort of blocking for year
> old versions of Flash in the immediate future. Is that now off the table? I
> haven't seen that clearly stated elsewhere.

Asa as well as the AMO team have stated that they do not want to blocklist with the given UX unless absolutely urgent, and the notification bar "block" was being discussed as a good balance between UX and the security of our users. There have been no other short term solutions proposed.
Comment 27 Robert Kaiser (not working on stability any more) 2012-05-21 13:39:37 PDT
(In reply to Alex Keybl [:akeybl] from comment #26)
> Asa as well as the AMO team have stated that they do not want to blocklist
> with the given UX unless absolutely urgent

The "absolutely urgent" makes me worry about tracking- here, though. If something with *any* plugin comes up that is urgent to block, we run into exactly this bug. If the patch is low enough risk, we should consider taking it as far up as possible to not make our lives even more difficult when something urgent comes up.
Comment 28 Alex Keybl [:akeybl] 2012-05-21 14:03:06 PDT
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #27)
> The "absolutely urgent" makes me worry about tracking- here, though. If
> something with *any* plugin comes up that is urgent to block, we run into
> exactly this bug. If the patch is low enough risk, we should consider taking
> it as far up as possible to not make our lives even more difficult when
> something urgent comes up.

If this problem is not specific to a Flash blocklist additions, the summary should be updated and we'll reconsider the nomination.
Comment 29 Josh Aas 2012-05-24 10:32:09 PDT
Working on this today...
Comment 30 Josh Aas 2012-05-25 15:02:17 PDT
Comment on attachment 625377 [details] [diff] [review]
Patch that allows to reload and use updated Plugins in a running browser session.

I've been talking with Stephen and others, we are going to go with another strategy. I should have a patch in the next few days.
Comment 31 Josh Aas 2012-05-28 20:08:35 PDT
Created attachment 627835 [details] [diff] [review]
fix v0.5

Here is the first half of a patch. It gets rid of all duplicate checking, allowing us to load every valid plugin on disk. The other half of the patch, which I hope to write tomorrow, will fix the search order for picking a plugin for a particular instance.
Comment 32 Josh Aas 2012-06-07 14:02:20 PDT
Created attachment 631127 [details] [diff] [review]
fix v1.0
Comment 33 Josh Aas 2012-06-07 14:11:21 PDT
This patch is not ready for review yet, btw, not a mistake that I didn't request review.
Comment 34 Josh Aas 2012-06-07 15:07:35 PDT
Created attachment 631168 [details] [diff] [review]
fix v1.1
Comment 35 Stephen A Pohl [:spohl] 2012-06-11 14:01:27 PDT
I asked one of our QEs to test this patch. The patch looks promising, but there appears to be a crash in Firefox when a tab is refreshed after an update to a Plugin occurred. 

Here are the findings:
"Tested on Win7 x64 and WinXP x86.

After installation completes, refreshing the browser tab that was open, with Flash content, during the upgrade results in a crash.

After installation completes, opening a new browser tab, or a new browser window, and viewing Flash content does not results in a crash.  The newly installed version is detected.

After installation completes and opening a new browser tab or window and viewing Flash content, and then returning to the tab that was opening during the upgrade and refreshing it does not result in a crash.  The newly installed version is detected.

The crash seems to occur only when refreshing the tab that was open during upgrade first, before launching another tab/window and viewing Flash content."

This is the output in VS2010:
Unhandled exception at 0x013ebce0 (xul.dll) in user.dmp: 0xC0000005: Access violation reading location 0x0000003c.

This is the call stack with out-of-process Plugins enabled:
>	xul.dll!mozilla::plugins::parent::_getproperty(_NPP * npp=0x071f4a08, NPObject * npobj=0x056d2248, void * property=0x033d08e0, _NPVariant * result=0x0012d2a4)  Line 1632	C++
 	xul.dll!mozilla::plugins::PluginScriptableObjectParent::AnswerGetParentProperty(mozilla::plugins::PPluginIdentifierParent * aId=0x075362b0, mozilla::plugins::Variant * aResult=0x0012d30c, bool * aSuccess=0x0012d300)  Line 913 + 0x12 bytes	C++
 	xul.dll!mozilla::plugins::PPluginScriptableObjectParent::OnCallReceived(const IPC::Message & __msg={...}, IPC::Message * & __reply=0x00000000)  Line 1108 + 0x1c bytes	C++
 	xul.dll!mozilla::plugins::PPluginModuleParent::OnCallReceived(const IPC::Message & __msg={...}, IPC::Message * & __reply=0x00000000)  Line 1276 + 0x9 bytes	C++
 	xul.dll!mozilla::ipc::RPCChannel::DispatchIncall(const IPC::Message & call={...})  Line 486	C++
 	xul.dll!mozilla::ipc::RPCChannel::Incall(const IPC::Message & call={...}, unsigned int stackDepth=2)  Line 472	C++
 	xul.dll!mozilla::ipc::RPCChannel::Call(IPC::Message * _msg=0x00000002, IPC::Message * reply=0x0012d430)  Line 281	C++
 	xul.dll!mozilla::plugins::PPluginModuleParent::CallNP_Shutdown(short * rv=0x0012d474)  Line 420	C++
 	xul.dll!mozilla::plugins::PluginModuleParent::NP_Shutdown(short * error=0x0012d474)  Line 784	C++
 	xul.dll!nsNPAPIPlugin::Shutdown()  Line 517	C++
 	xul.dll!nsPluginTag::TryUnloadPlugin(bool inShutdown=false)  Line 446	C++
 	xul.dll!nsPluginHost::ReloadPlugins(bool reloadPages=false)  Line 454	C++
 	xul.dll!mozilla::plugins::parent::_reloadplugins(unsigned char reloadPages=0)  Line 1157	C++
 	xul.dll!mozilla::plugins::PluginModuleParent::RecvNPN_ReloadPlugins(const bool & aReloadPages=false)  Line 1162 + 0xd bytes	C++
 	xul.dll!mozilla::plugins::PPluginModuleParent::OnMessageReceived(const IPC::Message & __msg={...})  Line 1139	C++
 	xul.dll!mozilla::ipc::AsyncChannel::OnDispatchMessage(const IPC::Message & msg={...})  Line 463 + 0xe bytes	C++
 	xul.dll!mozilla::ipc::RPCChannel::Call(IPC::Message * _msg=0x07197ab8, IPC::Message * reply=0x0012d5a4)  Line 215	C++
 	xul.dll!mozilla::plugins::PPluginModuleParent::CallPPluginInstanceConstructor(mozilla::plugins::PPluginInstanceParent * actor=0x0231f578, const nsCString & aMimeType={...}, const unsigned short & aMode=1, const InfallibleTArray<nsCString> & aNames={...}, const InfallibleTArray<nsCString> & aValues={...}, short * rv=0x0012d6a0)  Line 375 + 0x10 bytes	C++
 	xul.dll!mozilla::plugins::PluginModuleParent::NPP_New(char * pluginType=0x07418400, _NPP * instance=0x071f4a08, unsigned short mode=1, short argc=-2696, char * * argn=0x07361cb8, char * * argv=0x0558d498, _NPSavedData * saved=0x00000000, short * error=0x0012d6a0)  Line 867 + 0x37 bytes	C++
 	xul.dll!nsNPAPIPluginInstance::Start()  Line 445 + 0x24 bytes	C++
 	xul.dll!nsNPAPIPluginInstance::Initialize(nsNPAPIPlugin * aPlugin=0x07252720, nsIPluginInstanceOwner * aOwner=0x04356f58, const char * aMIMEType=0x050955f0)  Line 157 + 0x7 bytes	C++
 	xul.dll!nsPluginHost::TrySetUpPluginInstance(const char * aMimeType=0x050955f0, nsIURI * aURL=0x07a5ff30, nsIPluginInstanceOwner * aOwner=0x04356f58)  Line 1217 + 0x14 bytes	C++
 	xul.dll!nsPluginHost::InstantiateEmbeddedPluginInstance(const char * aMimeType=0x050955f0, nsIURI * aURL=0x07a5ff30, nsObjectLoadingContent * aContent=0x07a5fdb0, nsPluginInstanceOwner * * aOwner=0x07a5fe20)  Line 993 + 0x18 bytes	C++
 	xul.dll!nsObjectLoadingContent::InstantiatePluginInstance(const char * aMimeType=0x050955f0, nsIURI * aURI=0x07a5ff30)  Line 693 + 0x21 bytes	C++
 	xul.dll!nsObjectLoadingContent::SyncStartPluginInstance()  Line 2107 + 0xd bytes	C++
 	xul.dll!nsAsyncInstantiateEvent::Run()  Line 125	C++
 	xul.dll!nsThread::ProcessNextEvent(bool mayWait=false, bool * result=0x0012daab)  Line 624 + 0x9 bytes	C++
 	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0137e690, bool mayWait=false)  Line 213 + 0xd bytes	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x0137e6f0)  Line 82 + 0xa bytes	C++
 	xul.dll!MessageLoop::RunHandler()  Line 202	C++
 	xul.dll!MessageLoop::Run()  Line 176	C++
 	xul.dll!nsBaseAppShell::Run()  Line 165	C++
 	xul.dll!nsAppShell::Run()  Line 232 + 0x6 bytes	C++
 	xul.dll!nsAppStartup::Run()  Line 257	C++
 	xul.dll!XREMain::XRE_mainRun()  Line 3781 + 0x9 bytes	C++
 	xul.dll!XREMain::XRE_main(int argc=1, char * * argv=0x00374fe8, const nsXREAppData * aAppData=0x004032cc)  Line 3858 + 0x7 bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00374fe8, const nsXREAppData * aAppData=0x004032cc, unsigned int aFlags=0)  Line 3934 + 0x12 bytes	C++
 	firefox.exe!do_main(int argc=1, char * * argv=0x00000000)  Line 157 + 0x14 bytes	C++
 	firefox.exe!NS_internal_main(int argc=1, char * * argv=0x00374fe8)  Line 296 + 0xe bytes	C++
 	firefox.exe!wmain(int argc=0, wchar_t * * argv=0x00373d38)  Line 102	C++
 	firefox.exe!__tmainCRTStartup()  Line 552 + 0x17 bytes	C


This is the call stack with out-of-process Plugins disabled:
>	xul.dll!mozilla::plugins::parent::_getproperty(_NPP * npp=0x05b87d38, NPObject * npobj=0x039a78b0, void * property=0x0355a1c0, _NPVariant * result=0x0012d4b0)  Line 1632	C++
 	NPSWF32_11_4_400_150.dll! [removed] C++
 	NPSWF32_11_4_400_150.dll! [removed] C++
 	NPSWF32_11_4_400_150.dll! [removed] C++
 	xul.dll!mozilla::PluginPRLibrary::NPP_New(char * pluginType=0x05d262e0, _NPP * instance=0x05b87d38, unsigned short mode=1, short argc=11, char * * argn=0x05f9da50, char * * argv=0x05fa9560, _NPSavedData * saved=0x00000000, short * error=0x0012d6a0)  Line 195 + 0x17 bytes	C++
 	xul.dll!nsNPAPIPluginInstance::Start()  Line 445 + 0x24 bytes	C++
 	xul.dll!nsNPAPIPluginInstance::Initialize(nsNPAPIPlugin * aPlugin=0x052f2d58, nsIPluginInstanceOwner * aOwner=0x039646b0, const char * aMIMEType=0x03ba0dd8)  Line 157 + 0x7 bytes	C++
 	xul.dll!nsPluginHost::TrySetUpPluginInstance(const char * aMimeType=0x03ba0dd8, nsIURI * aURL=0x090dbbd8, nsIPluginInstanceOwner * aOwner=0x039646b0)  Line 1217 + 0x14 bytes	C++
 	xul.dll!nsPluginHost::InstantiateEmbeddedPluginInstance(const char * aMimeType=0x03ba0dd8, nsIURI * aURL=0x090dbbd8, nsObjectLoadingContent * aContent=0x090dba58, nsPluginInstanceOwner * * aOwner=0x090dbac8)  Line 993 + 0x18 bytes	C++
 	xul.dll!nsObjectLoadingContent::InstantiatePluginInstance(const char * aMimeType=0x03ba0dd8, nsIURI * aURI=0x090dbbd8)  Line 693 + 0x21 bytes	C++
 	xul.dll!nsObjectLoadingContent::SyncStartPluginInstance()  Line 2107 + 0xd bytes	C++
 	xul.dll!nsAsyncInstantiateEvent::Run()  Line 125	C++
 	xul.dll!nsThread::ProcessNextEvent(bool mayWait=false, bool * result=0x0012daab)  Line 624 + 0x9 bytes	C++
 	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0137e740, bool mayWait=false)  Line 213 + 0xd bytes	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x0137e7a0)  Line 82 + 0xa bytes	C++
 	xul.dll!MessageLoop::RunHandler()  Line 202	C++
 	xul.dll!MessageLoop::Run()  Line 176	C++
 	xul.dll!nsBaseAppShell::Run()  Line 165	C++
 	xul.dll!nsAppShell::Run()  Line 232 + 0x6 bytes	C++
 	xul.dll!nsAppStartup::Run()  Line 257	C++
 	xul.dll!XREMain::XRE_mainRun()  Line 3781 + 0x9 bytes	C++
 	xul.dll!XREMain::XRE_main(int argc=1, char * * argv=0x00374fc0, const nsXREAppData * aAppData=0x004032cc)  Line 3858 + 0x7 bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00374fc0, const nsXREAppData * aAppData=0x004032cc, unsigned int aFlags=0)  Line 3934 + 0x12 bytes	C++
 	firefox.exe!do_main(int argc=1, char * * argv=0x00000000)  Line 157 + 0x14 bytes	C++
 	firefox.exe!NS_internal_main(int argc=1, char * * argv=0x00374fc0)  Line 296 + 0xe bytes	C++
 	firefox.exe!wmain(int argc=0, wchar_t * * argv=0x00373d70)  Line 102	C++
 	firefox.exe!__tmainCRTStartup()  Line 552 + 0x17 bytes	C
 	kernel32.dll!7c817077() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]

In the call stack above, please note that NPSWF32_11_4_400_150.dll is the old Plugin. If the new Plugin had been loaded, NPSWF32_11_4_400_153.dll would have been displayed. This is expected behavior, as Flash Player will check if it has been updated during an NPN_New(). If so, it will call NPN_ReloadPlugins(false).
Comment 36 Stephen A Pohl [:spohl] 2012-06-11 14:03:58 PDT
I can't change the status of my review, but due to the crash, a review- might be appropriate until this crash is eliminated.
Comment 37 Benjamin Smedberg [:bsmedberg] 2012-06-11 14:44:12 PDT
Comment on attachment 631168 [details] [diff] [review]
fix v1.1

>diff --git a/dom/plugins/base/nsPluginHost.cpp b/dom/plugins/base/nsPluginHost.cpp

>+  for (unsigned int i = 1; i < matches.Length(); i++) {
>+    if (1 == mozilla::CompareVersions(matches[i]->mVersion.get(), preferredPlugin->mVersion.get())) {

This would be easier to read as:

if (mozilla::Version(matches[i]->mVersion.get()) > preferredPlugin->mVersion.get())

The patch looks correct. We should obviously investigate the crashing scenario.
Comment 38 Josh Aas 2012-06-11 15:12:22 PDT
Thanks Stephen! I'll look into it.
Comment 39 Josh Aas 2012-06-13 09:55:03 PDT
Created attachment 632747 [details] [diff] [review]
fix v1.1

This has a potential fix for the crash, though I don't have a way to test myself right now.
Comment 40 Josh Aas 2012-06-13 10:55:19 PDT
Comment on attachment 632747 [details] [diff] [review]
fix v1.1

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

Stephen from Adobe tested and the latest patch fixes the crash.
Comment 41 Josh Aas 2012-06-13 13:53:15 PDT
Pushed to try server:

https://tbpl.mozilla.org/?tree=Try&rev=3487ed66cbb1
Comment 42 Josh Aas 2012-06-13 15:43:19 PDT
Created attachment 632919 [details] [diff] [review]
fix v1.2

Forgot to address bsmedberg's comment about the version comparison code. Fixed in this patch.
Comment 43 Josh Aas 2012-06-13 19:52:14 PDT
pushed to mozilla-inbound

http://hg.mozilla.org/integration/mozilla-inbound/rev/7c92091ea0b8
Comment 44 Ed Morley [:emorley] 2012-06-14 02:44:45 PDT
https://hg.mozilla.org/mozilla-central/rev/7c92091ea0b8
Comment 45 Johnathan Nightingale [:johnath] 2012-06-22 07:00:20 PDT
Josh/Benjamin - how would we feel about uplifting this and bug 758363 across trains? I'm looking for ways to make it easier for Adobe to push out fixes. Are these 14-safe? Are they 13.0.2 safe?
Comment 46 Benjamin Smedberg [:bsmedberg] 2012-06-22 07:19:59 PDT
This is not risk-free: I think we would need some significant QA input in order to be comfortable taking this early. Particular areas of QA focus would be:

* Does the feature work correctly with Flash upgrades (from 10.2 to 10.3) while Firefox is running?
* Does the feature work correctly with Java upgrades while Firefox is running?
* After a Flash upgrade, does the enabled/disabled state persist correctly in the addons manager?
* During Flash upgrades, if you open the addon manager do both versions of Flash appear? What happens if you disable one or both of them? Does this persist reasonably after restart?
* After Java upgrade, does the enabled/disabled state persist in the addons manager?
* If both versions of Flash are running simultaneously for a while, does that cause any strange issue? This can happen if a page is using Flash (such as playing a movie or game) while the upgrade is taking place.
Comment 47 Alex Keybl [:akeybl] 2012-06-22 14:30:05 PDT
Comment on attachment 632919 [details] [diff] [review]
fix v1.2

[Triage Comment]
Please land on mozilla-release asap so that we can test using a tinderbox build. This is not yet shipping in a 13 release, however.
Comment 48 Alex Keybl [:akeybl] 2012-06-22 15:18:52 PDT
Comment on attachment 632919 [details] [diff] [review]
fix v1.2

Sadly Kyle let me know this patch does not apply cleanly to FF13 on mozilla-release.
Comment 49 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 15:22:49 PDT
I'm trying to arrange QA for this bug there are some things which are unclear.

What versions of Flash need testing? 10.2, 10.3, 11.2, 11.3, 11.4?
What upgrade paths? Update, Pave-over, Uninstall/Install?
How do I get two versions of Flash installed in a single Firefox instance?
Is the enable/disable triggered before update or after?
Do we need to test with updating from the 10.2 blocklist?

Same questions apply to Java.
Comment 50 Alex Keybl [:akeybl] 2012-06-22 16:10:52 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #49)
> I'm trying to arrange QA for this bug there are some things which are
> unclear.
> 
> What versions of Flash need testing? 10.2, 10.3, 11.2, 11.3, 11.4?

All tests can be from {blocked 10.2, latest 10.3, latest 11.2,11.3.300.257}->11.3.300.262. That should give us coverage.

> What upgrade paths? Update, Pave-over, Uninstall/Install?

Updates and pave-over.

> How do I get two versions of Flash installed in a single Firefox instance?

Benjamin may have to comment further, but my assumption is that this would only occur during the automatic Flash update process, if ever.

Triggering a Flash update through Flash may do the trick. Right-click on the plug-in and visited Global Settings, and use "check for updates".

> Is the enable/disable triggered before update or after?

Let us know what you find. I think the point is just to disable the plugin prior to update, and then see if it's enabled post update. we can compare to the behavior in 13.0.1 for reference.

> Do we need to test with updating from the 10.2 blocklist?

This would definitely provide clarity, yes.

> Same questions apply to Java.

Please use recent Java versions, and auto/manual updates and pave-over. I don't have a good recommendation for versions here.
Comment 51 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 18:02:24 PDT
FYI, QA will be going through the following testplan the next few hours with the latest Nightly:
https://wiki.mozilla.org/Releases/Firefox_13/Test_Plan#Bug_Verifications_2

Please email me at ahughes@mozilla.com with any red flags or revisions you see necessary to giving you the results your need to make any final calls for 13.0.2.
Comment 52 Benjamin Smedberg [:bsmedberg] 2012-06-22 20:15:36 PDT
When you install a new version of Flash and the old version is still in use by Firefox, both versions are installed side-by-side and are both available until the next *OS* restart. I believe that they will both show up in about:plugins and perhaps in the plugins view of the addon manager.

As for Java, I have no specific instructions. My specific concern is that a fair number of security-conscious people explicitly disable the Java plugin in the browser, and I want to make sure that this patch does not accidentally re-enable Java in any upgrade paths.

https://hg.mozilla.org/releases/mozilla-release/rev/d1af5c5c14be
Comment 53 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 20:25:44 PDT
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #52)
> When you install a new version of Flash and the old version is still in use
> by Firefox, both versions are installed side-by-side and are both available
> until the next *OS* restart. I believe that they will both show up in
> about:plugins and perhaps in the plugins view of the addon manager.

That's not what I'm seeing. 
* Install Firefox 16.0a1 2012-06-22 in Windows 7
* Install Flash 10.2
* Load vimeo.com and play a video
* Install Flash 11.3
> about:plugins only displays Flash 11.3
> Add/Remove Programs only displays Adobe Flash 11 Plugin
Comment 54 Stephen A Pohl [:spohl] 2012-06-22 20:48:49 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #53)
> > Add/Remove Programs only displays Adobe Flash 11 Plugin

Just wanted to chime in and say that the behavior in Add/Remove programs is controlled by the Flash Player installer, and the observed behavior is correct (only Adobe Flash Player 11 Plugin should be listed).
Comment 55 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 21:18:10 PDT
I was able to reproduce the side-by-side Flash in about:plugins...

1. Install Flash 11.3.300.257 64-bit
2. Install and start Firefox 16.0a1
3. Load vimeo.com
4. Download and install Flash 11.3.300.262 32-bit
5. Reload vimeo.com
6. Check about:plugins

I get 3 Flash versions:
 * NPSWF32_11_3_300_262.dll
 * NPSWF32_11_3_300_257.dll
 * NPSWF32_11_3_300_257.dll

Video on vimeo.com appears to play fine.
Reloading about:plugins keeps the three versions listed.
Restarting Firefox removes one of the 11.3.300.257 instances from about:plugins.
Restarting Windows removes the the other 11.3.300.257 instance from about:plugins.
Comment 56 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 21:39:26 PDT
Follow-up on the Java case...

1. Install Java 6u31
2. Install and start Firefox 16.0a1
3. Load http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html
4. Disable Java plug-in
5. Download and install Java 7u5
6. Reload Java tab
> PluginContainer prompts me to download Java. If I simply restart Firefox instead, Java is updated, enabled, and works as expected.

I'm not sure if restarting Firefox is an expected step.
Comment 57 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 22:15:35 PDT
Using the "install_flash_player.exe -install -iv 9" method to simulate automatic update from Flash 11.2, I get multiple copies of Flash in about:plugins, though Flash videos on vimeo.com appear to use 11.3.300.262.

The only way I can get rid of the extra entries in about:plugins is to either uninstall and reinstall the latest Flash or to restart Windows.
Comment 58 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 22:19:51 PDT
Additionally, it was asked of me to repeat the tests with dom.ipc.plugins.enabled=false. This appears to disable Flash, is this expected?
Comment 59 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 22:32:17 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #58)
> Additionally, it was asked of me to repeat the tests with
> dom.ipc.plugins.enabled=false. This appears to disable Flash, is this
> expected?

By "disabled" I don't mean they are disabled. In Add-ons Manager, Flash appears enabled but going to vimeo.com I can't play video.
Comment 60 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 22:35:09 PDT
Alex asked me to clarify the version of Flash being used when there are side-by-side versions in about:plugins. When playing video on vimeo.com Flash 11.3.300.262 (latest) is used.
Comment 61 Stephen A Pohl [:spohl] 2012-06-22 22:37:11 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #57)
> The only way I can get rid of the extra entries in about:plugins is to
> either uninstall and reinstall the latest Flash or to restart Windows.

This is expected behavior. The important thing is that the new (latest) version is used for any Flash content by default if multiple versions exist, which you have confirmed is the case.
Comment 62 Alex Keybl [:akeybl] 2012-06-22 23:38:44 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #58)
> Additionally, it was asked of me to repeat the tests with
> dom.ipc.plugins.enabled=false. This appears to disable Flash, is this
> expected?

I have not been able to reproduce this, and neither has Adobe.
Comment 63 Alex Keybl [:akeybl] 2012-06-22 23:46:13 PDT
Can somebody test these STR? Latest 16.0a1

1) Uninstall all versions of Flash
2) Install 11.3.300.257 using an old version installer
3) Go to http://www.youtube.com/watch?v=XbT0HV4-GjI&feature=g-logo-xit
4) Install 11.3.300.262 using Adobe's latest installer
5) Reload http://www.youtube.com/watch?v=XbT0HV4-GjI&feature=g-logo-xit

One time I got https://crash-stats.mozilla.com/report/index/bp-dcc291e0-0633-4f3d-a2cf-4a1a42120623 and then another time the browser completely hung and when I quit it I got http://crash-stats.mozilla.com/report/index/bp-ae0a4cd7-defe-47ad-88fd-616422120623. The second time I got dumps of all the Firefox and Flash processes before it crashed through Windows Task Manager.
Comment 64 Alex Keybl [:akeybl] 2012-06-22 23:47:06 PDT
One thing to note is that the version of Flash reported after updating to the latest version was 262.
Comment 65 Alex Keybl [:akeybl] 2012-06-22 23:57:48 PDT
Comment 63 does not reproduce in 13.0.1, likely because 11.3.300.257 is still used after update.
Comment 66 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-23 00:00:28 PDT
(In reply to Alex Keybl [:akeybl] from comment #63)
> Can somebody test these STR? Latest 16.0a1

Reproduced the hang and crash on exit.
Comment 67 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-23 00:06:26 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #66)
> (In reply to Alex Keybl [:akeybl] from comment #63)
> > Can somebody test these STR? Latest 16.0a1
> 
> Reproduced the hang and crash on exit.

The auto-update process seems to prevent this crash.
Comment 68 Alex Keybl [:akeybl] 2012-06-23 00:22:50 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #67)
> (In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #66)
> > (In reply to Alex Keybl [:akeybl] from comment #63)
> > > Can somebody test these STR? Latest 16.0a1
> > 
> > Reproduced the hang and crash on exit.
> 
> The auto-update process seems to prevent this crash.

Confirmed. So this regression only occurs when this patch is applied, you're using Flash, you use the manual installer, and you try to use Flash again. This may not be a very common scenario, but I'd still like to see if we can do anything to mitigate.
Comment 69 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-23 01:14:39 PDT
(In reply to Alex Keybl [:akeybl] from comment #68)
> This may not be a very common scenario, but I'd still like to see if we can
> do anything to mitigate.

I'm sure how uncommon it is either.
Comment 70 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-23 01:16:43 PDT
FYI, results of Firefox 16.0a1 2012-06-22 can be found here:
https://wiki.mozilla.org/Releases/Firefox_13/Test_Plan#Results

Note that I was not able to find an intuitive way to test Java updates on Mac, and Flash/Java updates on Linux. If anyone has some suggestions please indicate them either in this bug or via email. I'll be retesting this tomorrow for 13.0.2 candidates.
Comment 71 Benjamin Smedberg [:bsmedberg] 2012-06-23 05:31:03 PDT
The STR in comment 63 indicate a bug in the Flash player. Assuming that OOPP is still on in your test, we still load the Flash DLL into our main process in order to retrieve version and mimetype information for it. In this case (https://crash-stats.mozilla.com/report/index/bp-ae0a4cd7-defe-47ad-88fd-616422120623) we've loaded both versions of Flash into our process, and there are worker threads for both versions of Flash present. I don't think that this represents a bug in this patch.
Comment 72 Alex Keybl [:akeybl] 2012-06-23 08:22:37 PDT
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #71)
> The STR in comment 63 indicate a bug in the Flash player. Assuming that OOPP
> is still on in your test, we still load the Flash DLL into our main process
> in order to retrieve version and mimetype information for it. In this case
> (https://crash-stats.mozilla.com/report/index/bp-ae0a4cd7-defe-47ad-88fd-
> 616422120623) we've loaded both versions of Flash into our process, and
> there are worker threads for both versions of Flash present. I don't think
> that this represents a bug in this patch.

Thanks Benjamin - given that, we won't block on that issue. It'll cause users in that less common scenario to crash once. I expect most of our users will fall into the auto-update case anyway.

13.0.2 is about to be under way.
Comment 73 Stephen A Pohl [:spohl] 2012-06-23 08:36:47 PDT
(In reply to Alex Keybl [:akeybl] from comment #68)
> Confirmed. So this regression only occurs when this patch is applied, you're
> using Flash, you use the manual installer, and you try to use Flash again.
> This may not be a very common scenario, but I'd still like to see if we can
> do anything to mitigate.

Could you please tell us which "manual installer" you were using in this scenario? Thanks!
Comment 74 Alex Keybl [:akeybl] 2012-06-23 08:38:52 PDT
(In reply to Stephen A Pohl from comment #73)
> (In reply to Alex Keybl [:akeybl] from comment #68)
> > Confirmed. So this regression only occurs when this patch is applied, you're
> > using Flash, you use the manual installer, and you try to use Flash again.
> > This may not be a very common scenario, but I'd still like to see if we can
> > do anything to mitigate.
> 
> Could you please tell us which "manual installer" you were using in this
> scenario? Thanks!

http://www.oldapps.com/flash_player.php?old_flash_player=7792 for 257 and the download at http://get.adobe.com/flashplayer/ for 262.
Comment 75 Matthias Versen [:Matti] 2012-06-23 08:42:13 PDT
The manual Flash update blocks with Seamonkey running until Seamonkey is closed.
Does this depend on the application (Firefox vs Seamonkey) name ?

Note: 
A flash update hits the news pretty fast and many advanced users will update the flash plugin immediately manually since the adobe auto-update is either pretty slow or the auto-update is delayed by adobe (as we do with Firefox).
There are also many users who run Secunia PSI which updates flash. I don't know if the update by PSI counts as auto-update update or not.
Anyway, the crash should not be an issue if Adobe fixes that in their next Flash update
Comment 76 Alex Keybl [:akeybl] 2012-06-23 08:50:12 PDT
(In reply to Matthias Versen (Matti) from comment #75)
> The manual Flash update blocks with Seamonkey running until Seamonkey is
> closed.
> Does this depend on the application (Firefox vs Seamonkey) name ?

Can you give more information here? Were you using the STR in Comment 63? Was Flash loaded at the time of update?
Comment 77 Stephen A Pohl [:spohl] 2012-06-23 08:52:35 PDT
(In reply to Alex Keybl [:akeybl] from comment #63)
> One time I got
> https://crash-stats.mozilla.com/report/index/bp-dcc291e0-0633-4f3d-a2cf-
> 4a1a42120623 and then another time the browser completely hung and when I
> quit it I got
> http://crash-stats.mozilla.com/report/index/bp-ae0a4cd7-defe-47ad-88fd-
> 616422120623. The second time I got dumps of all the Firefox and Flash
> processes before it crashed through Windows Task Manager.

It appears that both crash dumps have been identified to be duplicates of https://bugzilla.mozilla.org/show_bug.cgi?id=763237. There doesn't seem to be a new issue here. Please let me know if this is not the case and/or if something needs further attention from our side.
Comment 78 Alex Keybl [:akeybl] 2012-06-23 08:56:05 PDT
(In reply to Stephen A Pohl from comment #77)
> It appears that both crash dumps have been identified to be duplicates of
> https://bugzilla.mozilla.org/show_bug.cgi?id=763237. There doesn't seem to
> be a new issue here. Please let me know if this is not the case and/or if
> something needs further attention from our side.

That signature is a crash bucket for all 11.3 crashes on Vista/Win7. This is a new issue that needs a bug on your end.
Comment 79 Stephen A Pohl [:spohl] 2012-06-23 09:06:08 PDT
(In reply to Alex Keybl [:akeybl] from comment #78)

> This is a new issue that needs a bug on your end.

Thanks Alex. Opened W3222047.
Comment 80 Matthias Versen [:Matti] 2012-06-23 09:07:38 PDT
(In reply to Alex Keybl [:akeybl] from comment #76)
> Can you give more information here? Were you using the STR in Comment 63?
> Was Flash loaded at the time of update?

I did the manual update yesterday. I had 11.3.300.257 installed on my win7/32bit system and downloaded the installer for 11.3.300.262 after a news message on heise.de and for reproducing another bug report in bugzilla.
The installer complained (as always in the past) that "the following application still runs -Seamonkey" and "the update will continue after closing the application."

This should not affect your 13.0.2 "mission" and you can ignore this for your Firefox release managing but i thought that it's worth to ask here.
Comment 81 Stephen A Pohl [:spohl] 2012-06-23 09:12:36 PDT
(In reply to Matthias Versen (Matti) from comment #80)
> (In reply to Alex Keybl [:akeybl] from comment #76)
> > Can you give more information here? Were you using the STR in Comment 63?
> > Was Flash loaded at the time of update?
> 
> I did the manual update yesterday. I had 11.3.300.257 installed on my
> win7/32bit system and downloaded the installer for 11.3.300.262 after a news
> message on heise.de and for reproducing another bug report in bugzilla.
> The installer complained (as always in the past) that "the following
> application still runs -Seamonkey" and "the update will continue after
> closing the application."

The difference might be the type of installer that you used. If you used the following installer, we expect that you are prompted to close the browser:
http://download.macromedia.com/pub/flashplayer/current/support/install_flash_player.exe

If you used the following installer, we expect that the installation completes without a prompt to close the browser:
http://get.adobe.com/flashplayer
Comment 82 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-23 09:42:35 PDT
(In reply to Stephen A Pohl from comment #81)
> The difference might be the type of installer that you used. If you used the
> following installer, we expect that you are prompted to close the browser:
> http://download.macromedia.com/pub/flashplayer/current/support/
> install_flash_player.exe

I confirm that this installer forces the user to close the browser and the crash/hang does not reproduce.

> If you used the following installer, we expect that the installation
> completes without a prompt to close the browser:
> http://get.adobe.com/flashplayer

I confirm that this installer works with Firefox open and reproduces the crash/hang.
Comment 83 Benjamin Smedberg [:bsmedberg] 2012-06-23 19:43:55 PDT
https://hg.mozilla.org/releases/mozilla-beta/rev/82c0c422a9cb
https://hg.mozilla.org/releases/mozilla-aurora/rev/e967f0934767

Although the tree looks pretty busted right now.
Comment 84 Robert Kaiser (not working on stability any more) 2012-06-30 11:23:44 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #56)
> Follow-up on the Java case...
> 
> 1. Install Java 6u31
> 2. Install and start Firefox 16.0a1
> 3. Load http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html
> 4. Disable Java plug-in
> 5. Download and install Java 7u5
> 6. Reload Java tab
> > PluginContainer prompts me to download Java. If I simply restart Firefox instead, Java is updated, enabled, and works as expected.
> 
> I'm not sure if restarting Firefox is an expected step.

Wait, doesn't this mean that Java gets unexpectedly enabled just in the way that bsmedberg said we don't want to happen (in comment #52)?
Comment 85 Benjamin Smedberg [:bsmedberg] 2012-07-03 14:02:56 PDT
https://hg.mozilla.org/releases/mozilla-beta/rev/a745cd4b5359 - Backed completely out of beta
https://hg.mozilla.org/releases/mozilla-beta/rev/91776a59d71b - and then relanded the bookkeeping fix related to NPP_New only:
Comment 86 Simona B [:simonab] 2012-07-05 06:25:33 PDT
Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0

The outdated Flash version is still displayed in the Add-ons Manager after updating to the latest version. The update is done without requesting a Firefox restart, the latest version of flash is used and 2 versions (11.2 and 11.3) are displayed in the about:plugins page.
It's not clear for me which is the state of the plug-in (in this case Flash) in the Add-ons Manager after an update. If both versions of Flash are displayed in the about:plugins page shouldn't both be also displayed in the Add-ons Manager?
Is it expected for the old version to be still displayed in the Add-on Manager but not the latest one? 
If restarting Firefox, the outdated version is still displayed in the Add-ons Manager, only restarting the OS displays the latest version.
Comment 87 Simona B [:simonab] 2012-07-05 06:51:05 PDT
(In reply to Simona B [QA] from comment #86)
> Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0
> 
> The outdated Flash version is still displayed in the Add-ons Manager after
> updating to the latest version. The update is done without requesting a
> Firefox restart, the latest version of flash is used and 2 versions (11.2
> and 11.3) are displayed in the about:plugins page.
> It's not clear for me which is the state of the plug-in (in this case Flash)
> in the Add-ons Manager after an update. If both versions of Flash are
> displayed in the about:plugins page shouldn't both be also displayed in the
> Add-ons Manager?
> Is it expected for the old version to be still displayed in the Add-on
> Manager but not the latest one? 
> If restarting Firefox, the outdated version is still displayed in the
> Add-ons Manager, only restarting the OS displays the latest version.

Tested on Windows XP with Firefox 14 beta 10 and updated Flash 11.2 to Flash 11.3.
Comment 88 Paul Silaghi, QA [:pauly] 2012-07-05 06:53:23 PDT
(In reply to Simona B [QA] from comment #87)
> (In reply to Simona B [QA] from comment #86)
> > Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0
> > 
> > The outdated Flash version is still displayed in the Add-ons Manager after
> > updating to the latest version. The update is done without requesting a
> > Firefox restart, the latest version of flash is used and 2 versions (11.2
> > and 11.3) are displayed in the about:plugins page.
> > It's not clear for me which is the state of the plug-in (in this case Flash)
> > in the Add-ons Manager after an update. If both versions of Flash are
> > displayed in the about:plugins page shouldn't both be also displayed in the
> > Add-ons Manager?
> > Is it expected for the old version to be still displayed in the Add-on
> > Manager but not the latest one? 
> > If restarting Firefox, the outdated version is still displayed in the
> > Add-ons Manager, only restarting the OS displays the latest version.
> 
> Tested on Windows XP with Firefox 14 beta 10 and updated Flash 11.2 to Flash
> 11.3.

Same behavior on Win 7 32-bit on FF 14b11.
Comment 89 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-07-05 09:57:56 PDT
Yes, this is all expected. The point of this bug was to make sure the latest Flash version was being used even though multiple versions are being listed in about:plugins. The only way to clean up about:plugins is to restart the OS. As long as the latest Flash version is being used we are good.
Comment 90 Simona B [:simonab] 2012-07-12 08:20:43 PDT
Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20100101 Firefox/14.0

If I install Flash 11.3.300.257 and I pave over with Flash 11.3.300.262 - the used Flash version after restarting Firefox 14 beta 12 is the latest one (11.3.300.262). 

But, if over Flash 11.3.300.262 I pave with 11.3.300.265 then the used Flash version in Firefox 14 beta 12 is still the old one (11.3.300.262). The only way the that Flash 11.3.300.265 is used is if I restart the OS. 

On the other hand, on the latest Nightly - the latest flash version is used after updating it - no OS restart is needed.
Comment 91 Benjamin Smedberg [:bsmedberg] 2012-07-12 10:00:31 PDT
Simona, please avoid spamming the bug with expected results: you can see that this was backed out of 14.
Comment 92 Benjamin Smedberg [:bsmedberg] 2012-07-12 10:46:44 PDT
Aurora backout: https://hg.mozilla.org/releases/mozilla-aurora/rev/21c619c0ec82
And relanding only the necessary bits, so that Aurora should now match beta: https://hg.mozilla.org/releases/mozilla-aurora/rev/069a10488f9b
Comment 93 Georg Fritzsche [:gfritzsche] [away Jun 24 - Jul 3] 2012-07-19 15:03:41 PDT
Created attachment 644029 [details] [diff] [review]
Backout changes from Aurora completely.
Comment 94 Georg Fritzsche [:gfritzsche] [away Jun 24 - Jul 3] 2012-07-19 15:04:17 PDT
Created attachment 644030 [details] [diff] [review]
Reapply bookkeeping fix only to Aurora.
Comment 96 Benjamin Smedberg [:bsmedberg] 2012-10-10 09:15:40 PDT
*** Bug 799571 has been marked as a duplicate of this bug. ***

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