User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5) Gecko/20100610 MozillaDeveloperPreview/3.7a5 ( .NET CLR 3.5.30729; .NET4.0E) Build Identifier: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:18.104.22.168) Gecko/20100611 Firefox/3.6.4 ( .NET CLR 3.5.30729) i have observed that on a newly installed winxp/x86 machine (sp3) which was running firefox 3.6.3 as the very first mozilla product and upgraded to 3.6.4 tonight the silverlight websites run fine from inside the OOPP subprocess plugin-container.exe. when i rightclick inside the silverlight objects and select the silverlight context menu the Silverlight.Configuration.exe process is again a subprocess of the plugin-container.exe OOPP subprocess. so far so good. on a similar machine (winxp, sp3), but with a long-term firefox usage (maybe even since firefox 1.x, with constant updates/upgrades), firefox upgraded to 3.6.4 last night as well, but with silverlight sites on this machine they are directly started inside the main firefox.exe process, and also the rightclick and Silverlight.Configuration.exe process is a direct child process of firefox.exe but only for silverlight objects. flash objects create and run normally from the plugin-container.exe on both firefox installations. this second machine has never fiddled with the about:config area or did any sort of beta testing or alpha builds or whatsoever regarding to the firefox product. both machines have german winxp professional, sp3, latest patches. run normally. verified the processes and process trees with sysinternals/processexplorer. flash works normally inside OOPP on both machines. both machines have latest plugins/addons when checking on mozilla.com/pugincheck is there somewhere a config setting for OOPP so that various plugins run either inside or outside of the plugin subprocesses? what am i doing wrong? bug? thanks and regards. Reproducible: Always
i have found additional systems (same winxp, professional, sp3, german) with long-term firefox usage as well, which had been updated from 3.6.3 to 3.6.4 today, and which all lack the oopp functionaly when being run on microsoft silverlight pages. silverlight runs directly from the firefox.exe process on these machines, flash runs from the container subprocess. maybe an additional hint: these affected machines were probably silverlight 2.x and 3.x users as well, but already had updated silverlight to 4.x in the recent weeks. the one machine i have had so far were silverlight (4.x) actually worked from inside the container.exe subprocess was a very new clean install of windows xp, so it probably directly went to silverlight 4.x immediately via windowsupdate, and didnt have any previous versions of silverlight 2.x or 3.x installed. maybe that could be some reason for the problems? although as far as i can tell inside the "%programfiles%\microsoft silverlight\" folder there is only the 4.x subfolder on all these machines and there can only be a single version of silverlight installed on windows machines if i am not mistaken. well whatever, so silverlight basically gives me strange behaviour and doesnt make use of oopp on all of my machines except for exactly one. so there has to be some reason for this unintended(?) behaviour. regards.
about:config and filter for "ipc" shows always the same "default" settings on all the affected machines, both the normally working oopp-silverlit and oopp-silverunlit firefox ones. weird. dom.ipc.plugins.enabled;false dom.ipc.plugins.enabled.npctrl.dll;true dom.ipc.plugins.enabled.npqtplugin.dll;true dom.ipc.plugins.enabled.npswf32.dll;true dom.ipc.plugins.enabled.nptest.dll;true dom.ipc.plugins.timeoutSecs;10 the status column shows "default" everywhere. the machine that i just checked is an english winxp professional, sp3, latestpatches, en-us firefox 3.6.3 upgraded to 3.6.4 last night, longterm windows(silverlight) and longterm firefox usage. this en-us ffx/winxp machine is also lacking the plugin-container.exe process for the silverlight subsystem. whats happening? :(
Try Firefox's safe mode for the computer that will not run Silverlight.Configuration.exe as a separate process. http://support.mozilla.com/en-US/kb/Safe+Mode
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → 1.9.2 Branch
Can you tell us what version of silverlight you have on these machines via about:plugins?
one machine with 3.6.4 (longterm ffx usage), winxp sp3, english everything: where silverlight doesnt run from inside container but from inside main process. Silverlight Plug-In File: npctrl.1.0.30716.0.dll Version: 4.0.50524.0 4.0.50524.0 MIME Type Description Suffixes Enabled application/x-silverlight npctrl scr Yes application/x-silverlight-2 Yes ------------- Directory of C:\Program Files\Microsoft Silverlight 09.06.2010 10:32 <DIR> . 09.06.2010 10:32 <DIR> .. 09.06.2010 10:04 <DIR> 4.0.50524.0 23.05.2010 21:38 489.296 sllauncher.exe 23.05.2010 21:38 19.808 xapauthenticodesip.dll 2 File(s) 509.104 bytes --------------------- will attach some screenshots (processexplorer/sysinternals) that shows the silverlightconfig process running as a parent from firefox.exe and the plugincontainer.exe working normally for the flash.dll subsystem
Created attachment 453990 [details] no plugincontainer for silverlight 4 on 3.6.4/english, win32/xp/sp3/english
Created attachment 453992 [details] plugincontainer for flash 10.1 on 3.6.4/english, win32/xp/sp3/english works fine
other machine, german/xp/sp3 german/ffx/364/shorttermusage(upgraded from 363) works normally via plugincontainer.exe for both flash 10.1 and silverlight 4 -------- Silverlight Plug-In Datei: npctrl.dll Version: 4.0.50524.0 4.0.50524.0 MIME-Typ Beschreibung Endungen Aktiviert application/x-silverlight npctrl scr Ja application/x-silverlight-2 Ja ----------- Shockwave Flash Datei: NPSWF32.dll Version: 10.1.53.64 Shockwave Flash 10.1 r53 MIME-Typ Beschreibung Endungen Aktiviert application/x-shockwave-flash Adobe Flash movie swf Ja application/futuresplash FutureSplash movie spl Ja ----------------- C:\Programme\Microsoft Silverlight\4.0.50524.0>dir npctrl*.* Datentraeger in Laufwerk C: ist WinXPProOEMGer Verzeichnis von C:\Programme\Microsoft Silverlight\4.0.50524.0 23.05.2010 23:30 1.013.760 npctrl.dll 23.05.2010 23:30 760.832 npctrlui.dll 2 Datei(en) 1.774.592 Bytes ----------------------- what i found out that there is an additional copy of the npctrl.dll (silverlight 4 component) on the english machine (longterm usage) with that other old-style (?) name: C:\>dir npctrl*.* /S /A Volume in drive C is WinXP Directory of C:\Program Files\Microsoft Silverlight\4.0.50524.0 23.05.2010 23:30 1.013.760 npctrl.1.0.30716.0.dll 23.05.2010 23:30 1.013.760 npctrl.dll 23.05.2010 23:30 760.832 npctrlui.dll 3 File(s) 2.788.352 bytes the contents of the npctrl.1.0.30716.... file is the very same as the plain npctrl.dll file C:\Program Files\Microsoft Silverlight\4.0.50524.0>fc npctrl.1.0.30716.0.dll npc trl.dll Comparing files npctrl.1.0.30716.0.dll and NPCTRL.DLL FC: no differences encountered C:\Program Files\Microsoft Silverlight\4.0.50524.0>md5sums npctrl*.* [Path] / filename MD5 sum ------------------------------------------------------------------------------- [C:\Program Files\Microsoft Silverlight\4.0.50524.0\] npctrl.1.0.30716.0.dll 2cb7c019a1ab8ea3d281c9606d097331 npctrl.dll 2cb7c019a1ab8ea3d281c9606d097331 npctrlui.dll 4af4fbeead89f001dd368166961be97f maybe some remainders of older silverlight installations and silverlight upgrade procedures and longterm firefox usage? like i reported before i found quite a number of machines that lacked the plugincontainer.exe process for silverlight (german winxp/ffx), i can probably check there for this potential additional silverlight dll file with this other name and leftovers, maybe thats some reason for this odd firefox behaviour. maybe firefox sourcecode only strictly uses plugincontainer modules for exactly specified plugin-dlls and their names? cheers.
hah, i found the origin of this behaviour: i couldnt check for some other machines, so i simply tried to mess the perfectly working machine up a bit, by simply duplicate the npctrl.dll file existing there in the silverlight directory to a second file named like on the buggy machine. as soon as you have a two files (identical) named npctrl.1.0.30716.0.dll and npctrl.dll in the "%programfiles%\Microsoft Silverlight\4.0.50524.0\" and start firefox 3.6.4 then, and navigate to a silverlight site then (i use the http://www.weishare.net msft site for testing) firefox 3.6.4 wont use the plugincontainer encapsulated method for silverlight any more. about:plugins shows this renamed dll file for silverlight as well this way. Silverlight Plug-In Datei: npctrl.1.0.30716.0.dll Version: 4.0.50524.0 4.0.50524.0 MIME-Typ Beschreibung Endungen Aktiviert application/x-silverlight npctrl scr Ja application/x-silverlight-2 Ja -------------------- so this has to be the origin of this buggy behaviour. i guess these machines that i have access to are not the only longterm users of firefox and silverlight and potentially a lot of users are most likely affected by this situation. regards.
This would be because we explicitly whitelist the plugins by name, and the whitelist entry for Silverlight is for "npctrl.dll". http://mxr.mozilla.org/mozilla1.9.2/source/browser/app/profile/firefox.js#917
i really do wonder who is in charge of all this mess, at microsoft i mean or how all of this plugin system ever since the netscape days, interacts with each other. why does firefox or mozilla apps pick this renamed additional dll on a clean silverlight4-only (no other silverlight had been installed on this originally normally working german winxp/ffx) instead of using the actual npctrl.dll file which as been installed and deployed by the silverlight4 installer and microsoft. so firefox just takes random dlls in previously defined plugin directories or something? there is zero reference to this renamed file on this originally working and clean system, so why does it get loaded and used and thus being excluded from the plugincontainer method etc. very weird if you ask me. additionally this whole mess probably created by microsoft and their coding standards, when you came the long way from earlier silverlight versions why do they copy over or recreate this renamed dll file which is exactly the same as the normal npctrl.dll file in the first place. :( so firefox is failing to provide this new enhanced security and sub-process encapsulation with 3.6.4 for all the users out there who didnt exactly have a clean silverlight 4 version as their first silverlight installation but had previous upgrades from the silverlight product. wouldnt it be better to additionally check the versions or signatures (authenticode) and whatnot of the products you actually develop your container method for. whitelist with just filenames is pretty low standard in my opinion, and these renamed files from previous versions or compatibility leftovers or whatever this **** is, seriously interferes with your way to handle the plugin dlls. :(
i made some additional repros, fresh winxp, fresh firefox 3.6.4 as first browser. (using old silverlight version installers) whenever the user has installed and used silverlight 1.0 microsoft creates that additional dll with the version number and will keep it that way even with upgrades to 2.0, 3.0 and 4.0 silverlight versions. so when coming all the way from silverlight 1.0 firefox will not run silverlight in the plugincontainer subprocess. when starting with silverlight 2.0 or anything higher as the first silverlight version to be installed, the container stuff works normally (there will be only a npctrl.dll file created in the silverlight directories) too bad for longtime silverlight users any solutions to this problem? what would be the most elegant or feasible way to handle this matter?
http://www.michielpost.nl/Silverlight/MultiFileUploader/ Silverlight would not load in case of OOPP enabled on both latest Namoroka and Minefied. Silverlight Plug-In 4.0.50524.0 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:22.214.171.124pre) Gecko/20100626 Namoroka/3.6.7pre ID:20100626041846 Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100626 Minefield/3.7a6pre ID:20100626035857
I'm marking this bug as WONTFIX per bug #1269807. For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.