893671 - XBAP crashes browser when plugin is loaded under version 22.0

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[William]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36

Steps to reproduce:

1.  Open the browser
2.  Browse to location of XBAP


Actual results:

Causes the browser the freeze up.  Although it recovers about a minute later (sometimes a couple of minutes), the XBAP is never loaded and displays a white box where it should be.


Expected results:

It should of loaded, as it did before under version 21.0

Comment 1

[William]

I have the windows Presentation Foundation 3.5.30729.1 installed, which is the same version I have been using in older versions of FireFox.

Comment 2

[Loic]

Provide a testcase or URL, so we could test. What's XBAP?

Comment 3

[William]

XBAP is an XAML Browser Application, see here for info and examples of XBAPs, which also crash FireFox v22.0

http://www.xbap.org/

Comment 4

[Loic]

Is there a need to install a binary before testing XBAP samples?

Anyway, if the plugin crashes with FF22, ask XBAP support.

Comment 5

[William]

You need the plugin available from .NET Framework 3.5 NPWPF.DLL (Windows Presentation Foundation 3.5.30729.1).  This is what loads the XBAPS.  This worked on all previous version of FireFox.

Comment 6

[Loic]

http://social.msdn.microsoft.com/Forums/vstudio/en-US/747c6b78-a821-4498-a37f-1b79197de803/xbap-plugin-for-firefox-in-windows-7

Unfortunately, the release of the XBAP Firefox plug-in for Windows 7 has been continuously delayed, for inexplicable process reasons. Hang in there.

An interim solution just for testing is to transplant the plug-in from a .NET Framework installation on Windows XP or Vista. Version 4 is better (even for running v3.5 applications), but it requires another DLL or two from .NET 4, so go for it only if you have .NET 4 installed on Windows 7. The source location is:

    c:\Windows\Microsoft.NET\Framework\v3.5\WPF\NPWPF.dll - for v3.5 [SP1]
    c:\Windows\Microsoft.NET\Framework\WPF\NPWPF.dll - for v4 

The easiest way to transplant it is to copy the DLL to c:\Program Files\Mozilla Firefox\plugins\. Or, if you want to keep the normal location, put the DLL there and run regsvr32.exe on it.

Comment 7

[Loic]

I can't test, I don't have this WPF plugin in folder c:\Windows\Microsoft.NET\Framework\v3.5\WPF\

Comment 8

[William]

If you don't have the plugin located and FireFox installed, you will need to uninstall and re-install .NET Framework 3.5 SP1 again.  This will ensure FireFox is detected and the plugin is installed.

Comment 9

[Loic]

.NET Framework 3.5 and 4.0 are already installed on my computer. Anyway, I'll not reinstall .NET to test an almost EOLed plugin on Win 7.

As you're able to reproduce the issue, could you install mozregression on your computer to try to find a possible regression range (see http://harthur.github.io/mozregression/ for details).

FF22 nightlies started in Feb 2013 (mozregression --good=2013-02-01).

Comment 10

[Mike Peterson]

I have the same issue and attempted to confirm using the nightlies.  However, the regression builds do not handle XBAP applications the same way as the installed executable.  So it is difficult to test from that perspective.  However, I can confirm that the behavior is the same for our XBAP applications as what was described in the initial bug description, and that it started at build 22.

Comment 11

[Loic]

(In reply to Mike Peterson from comment #10)
> I have the same issue and attempted to confirm using the nightlies. 
> However, the regression builds do not handle XBAP applications the same way
> as the installed executable.  So it is difficult to test from that
> perspective.  However, I can confirm that the behavior is the same for our
> XBAP applications as what was described in the initial bug description, and
> that it started at build 22.

You can use your current profile (or a test profile) with mozreg (see the command --profile). Can you restest with that, please?

Comment 12

[Loic]

(of course, you need to install this XBAP plugin in your test profile before running mozreg).

Comment 13

[Mike Peterson]

(In reply to Loic from comment #11)
> (In reply to Mike Peterson from comment #10)
> > I have the same issue and attempted to confirm using the nightlies. 
> > However, the regression builds do not handle XBAP applications the same way
> > as the installed executable.  So it is difficult to test from that
> > perspective.  However, I can confirm that the behavior is the same for our
> > XBAP applications as what was described in the initial bug description, and
> > that it started at build 22.
> 
> You can use your current profile (or a test profile) with mozreg (see the
> command --profile). Can you restest with that, please?

I just tried that.  The problem is that the application does not launch from the normal location and that causes a problem with it trying to access WPF.  I am not sure that this can be tested using mozregression.  Is there another route we can go down to do this?  Is there anywhere to download and install previous packages to get a before/after comparison?

Comment 14

[Loic]

Mike, could you try https://support.mozilla.org/en-US/kb/windows-media-or-other-plugins-stopped-working with your testing profile then use mozreg with this profile.

In addition, can I download and install this WPF plugin to test?
Because I read "You cannot install the WPF plug-in for Firefox on Windows 7." on MS doc (http://msdn.microsoft.com/en-us/library/cc716877.aspx).

So it would help if you could provide STR to install and run XBAP apps easily.

Comment 15

[Ray Maynard]

Have tried copy npwpf.dll to plugins. I can see "Windows Presentation Foundation 3.5.30729.1" in my Firefox plugins. XBAP tries to load, but Freezes as per Williams original comment.

I have installed FF 3.6 with the same plugin - works fine. We need this fixed asap as major project relies on it. Only other solution is to get userbase (100s) to use IE and discontinue the FF choice as We can not get them all to downgrade to 3.6

Comment 16

[Loic]

XBAD seems to be EOLed, quote:

"Unfortunately, the release of the XBAP Firefox plug-in for Windows 7 has been continuously delayed, for inexplicable process reasons. Hang in there.

An interim solution just for testing is to transplant the plug-in from a .NET Framework installation on Windows XP or Vista. Version 4 is better (even for running v3.5 applications), but it requires another DLL or two from .NET 4, so go for it only if you have .NET 4 installed on Windows 7. The source location is:

    c:\Windows\Microsoft.NET\Framework\v3.5\WPF\NPWPF.dll - for v3.5 [SP1]
    c:\Windows\Microsoft.NET\Framework\WPF\NPWPF.dll - for v4 

The easiest way to transplant it is to copy the DLL to c:\Program Files\Mozilla Firefox\plugins\. Or, if you want to keep the normal location, put the DLL there and run regsvr32.exe on it."

Comment 17

[Ray Maynard]

Thanks Loic (Comment 16) but that is what I had already done. Prior to doing the dll copy, the plugin was not available. Now it is BUT does not work. It causes the browser to freeze, first with a black box, then a white one.

The same NPWPF.dll runs in FireFox 3.6. on the same machine. (win 7 64 Bit).
At present any XBAP only works in IE 9 and above, and (with some fiddling) Chrome. Our userbase is split pretty much 50-50 between IE and FF.  If we have to tell them we only support IE there may be grief (but I suppose it simplifies testing).

Comment 18

[Loic]

Is it possible to attach NPWPF.dll to this bug (I'm on Win 7), so I could download it and test on my side, because I don't have it in the folders of the .NET framework (and I don't want to reinstall outdated .NET packages).

Anyway, as somebody said in the link I provided, maybe it's better to move your application on Silverlight or another technology in the future, especially since Microsoft has discontinued the support of this XBAP plugin.
Remember Firefox 3.6 is not supported anymore (and full of security failures), and Mozilla encourages corporates to use Firefox ESR on their machines.

Comment 19

[Ray Maynard]

Attachment: NPWPF.dll

NPWPF.dll as requested. Works with FF 3.6 not with FF 22+.
It resides in C:\Program Files (x86)\Mozilla Firefox\plugins folder on my Win 7 64 Bit

Comment 20

[Loic]

STR:

1) Create a new profile (see https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles)
2) Download the file NPWPF.dll (Windows Presentation Foundation 3.5.30729.1) and save it in the folder \Plugins inside the profile folder (create this folder because it's missing by default)
3) Start mozregression with the command --profile
4) Open the page http://www.xbap.org/TicTacToe/publish.htm and click on the "launch" link.

Result: a black window should appear (I guess the app is broken due to the error message, but whatever, it's not the issue here) but instead the browser freezes and must be killed in the task manager.

Reg range:
good=2013-03-27
bad=2013-03-28
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=178a4a770bb1&tochange=962f5293f87f

NB: the plugin Windows Presentation Foundation 3.5.30729.1 can be tested in FF25 by saving the DLL in C:\Program Files (x86)\Mozilla Firefox\plugins\

Comment 21

[Alice0775 White]

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/8695e3fd2d34
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130326 Firefox/22.0 ID:20130326234208
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/61b8a5101c5b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130327 Firefox/22.0 ID:20130327020206
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8695e3fd2d34&tochange=61b8a5101c5b


In local build,
Last Good: 2ab72bbb04db\
First Bad: 20454bf62bb1\
Regressed by: 
20454bf62bb1	Mike Hommey — Bug 852950 - Kill libxpcom. r=bsmedberg Also refactored the xpcom standalone glue to reside in a single file and removed its use of realpath().

Comment 22

[Georg Fritzsche [:gfritzsche]]

Can we have a crash report using the tool in [1] so that we have a stack to look at?

[1] https://developer.mozilla.org/en-US/docs/How_to_Report_a_Hung_Firefox

Comment 23

[Loic]

CR made with the last Nightly:
https://crash-stats.mozilla.com/report/index/24ffc76c-c970-430e-8bdc-1920f2131123
https://crash-stats.mozilla.com/report/index/b7ab1e29-eb7d-4fbe-b7bf-ecd3d2131123

Comment 24

[Georg Fritzsche [:gfritzsche]]

Those are both hanging with waits in GeckoChildProcessHost::SyncLaunch() [1]. The plugin container fails to start or crashes, so we continue after our 45sec timeout passed. 
The question is now why the plugin container fails to start. We don't have a crash reporter attached at that stage though, so someone needs to look at it with a debugger.

http://dxr.mozilla.org/mozilla-central/source/ipc/glue/GeckoChildProcessHost.cpp#304

Comment 25

[Georg Fritzsche [:gfritzsche]]

Comment 0 says the browser recovers after a minute while comment 20 just says that the browser freezes and must be killed.
Loic, does it start working for you again after 45sec (or whatever dom.ipc.plugins.processLaunchTimeoutSecs is set to)? If you're using a debug build the pref will be 0 and not time out, but it should when you set it to 45.

Comment 26

[Loic]

The black screen of the app appears after 1 min or 2, but if I click again in the window, the hang is back, so the browser doesn't really recover, it stays in a quasi-permanent hang mode. Anyway the browser cannot be used in such a situation.

I tried with dom.ipc.plugins.processLaunchTimeoutSecs=0, it's a permanent hang.

Comment 27

[Benjamin Smedberg]

Given the regression range, it appears that the plugin was linking against a DLL (probably xpcom.dll) that no longer exists. That was an unsupported configuration to begin with. I am surprised, however, that we wouldn't detect this situation immediately here http://hg.mozilla.org/mozilla-central/annotate/757c2011df5b/dom/plugins/ipc/PluginModuleChild.cpp#l187 rather than waiting for the long timeout.

Firefox code should be fixed so that the plugin fails to load immediately and there is no hang. The XBAP plugin needs to be fixed to stop linking against DLLs that it shouldn't.

Comment 28

[Loic]

This plugin is not supported anymore by MS, I'm not we can expect a fix.

Comment 29

[Ray Maynard]

But previous FF worked (and still work) with the same plugin on the same machine. 
Looking at similar bug (902404), should we be registering the NPWPF.dll (and others?) If so any script suggestions?

Comment 30

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.