[OOPP] silverlight doesnt always run inside plugin-container.exe (winxp, x86), ffx 3.6.4

RESOLVED WONTFIX

Status

()

Core
Plug-ins
RESOLVED WONTFIX
8 years ago
a year ago

People

(Reporter: abittner, Unassigned)

Tracking

1.9.2 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
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:1.9.2.4) 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
(Reporter)

Comment 1

8 years ago
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.
(Reporter)

Comment 2

8 years ago
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? :(

Comment 3

8 years ago
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

Updated

8 years ago
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → 1.9.2 Branch

Comment 4

8 years ago
Can you tell us what version of silverlight you have on these machines via about:plugins?
(Reporter)

Comment 5

8 years ago
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
(Reporter)

Comment 6

8 years ago
Created attachment 453990 [details]
no plugincontainer for silverlight 4 on 3.6.4/english, win32/xp/sp3/english
(Reporter)

Comment 7

8 years ago
Created attachment 453992 [details]
plugincontainer for flash 10.1 on 3.6.4/english, win32/xp/sp3/english works fine
(Reporter)

Comment 8

8 years ago
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.
(Reporter)

Comment 9

8 years ago
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
(Reporter)

Comment 11

8 years ago
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.

:(
(Reporter)

Comment 12

8 years ago
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?

Comment 13

8 years ago
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:1.9.2.7pre) 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.