User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17 Steps to reproduce: Open any page with content using the Unity plugin on a Mac, such as http://files.unity3d.com/webplayer_test/input3x/InputTest3x.html Actual results: The plugin-container process crashes in an strlen function call. Expected results: The content should play. This is a regression from Firefox 17. Further investigation and comparison with other plugins which don't crash revealed that the reason for the crash is that the Unity Web Player does not have a "WebPluginDescription" entry in it's Info.plist file. Probably Firefox is now expecting this string to be present and not having it causes a crash in strlen. While this is easy for us to fix in the next release, it would be great if this can be fixed in Firefox ASAP, as a fix from our side will require users to download and install a new plugin.

Do you have a crash id from about:crashes that you can post here ?

I believe this one should probably be relevant given it's time stamp, but I cannot inspect it, as it says "We couldn't find the OOID you're after. If you recently submitted this crash, it may still be in the queue.": https://crash-stats.mozilla.com/report/index/bp-986041bc-0c63-448c-acec-2d5fc2130110

I get a hang with trunk builds Last good nightly: 2012-12-13 First bad nightly: 2012-12-14 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=edd45de440ba&tochange=b11065872128

Please ignore the regression range from comment#3. I get changing results with my regression range search :-( I get crash reports like this one bp-65c93447-6f8c-4c31-b8ec-b073b2130110 and the crash ID from the reporter seems to be processed and looks a little bit longer. ASAP in Firefox would be the next Firefox release (19) unless we do a chemspill 18.0.1 release.

It sounds like this issue is specific to Mac. As it is specific, I thought it would be valuable to add some numbers to that. Here is the the Unity Player stats on OS breakdown so we can gauge the risk of a chem spill. http://unity3d.com/webplayer/hwstats/pages/web-2012Q4-os.html

I cannot reproduce this on Nightly x86-64: File: Unity Web Player.plugin Version: UnityPlayer version 3.1.0f4 MIME Type Description Suffixes application/vnd.unity Unity Player unity3d It appears that the plugin is x86/ppc and doesn't have an x86-64 version, so we're running it cross-arch. The crash-stats data is mostly useless because of missing symbols.

I haven't been able to reproduce the crash. However when I open the page in Firefox 17 the plugin loads fine, but in Firefox 18 it hangs for a while before it complains with an unresponsive script error: "Script: http://files.unity3d.com/webplayer_test/input3x/unityobject.js:93"

So far in the worse case scenario for me, if I keep clicking on Continue when I get the unresponsive script prompts, the browser freezes. If I click on Stop then I get a responsive browser, but the plugin doesn't load.

As Matthias points out, there are a lot of crashes when I go to about:crashes but they are empty: bp-b1d6ab1e-8db8-4be2-9c99-3920e2130110

I've CC'd Steven since he may have been doing related plugin work recently.

I'm getting to this now (I've been sidetracked by other things). And I *am* able to reproduce it ... I think.

I can reproduce this with FF18 release. I cannot reproduce with http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/11/2012-11-17-04-20-12-mozilla-aurora/firefox-18.0a2.en-US.mac.dmg which is the Aurora 18 nightly right before the 18 train moved to beta. Weird.

> I can reproduce this with FF18 release. Likewise. But I can't reproduce this even in today's mozilla-central nightly (using the example from comment #0) -- even though that example doesn't display properly. I wonder if the Unity plugin changes its behavior according to which browser it thinks it's running it.

I've narrowed the regression down to 18b4 and 18b6, and by inspecting the changelog I think the following changeset is the problem: http://hg.mozilla.org/releases/mozilla-release/rev/3fbda0a1a6e9?revcount=120#l2.26 We're calling nsDependentCString(info.fDescription) when info.fDescription may be null. This was subsequently fixed on trunk in bug 825620.

In which case this bug should happen in the 2013-01-04 mozilla-central nightly but not in the 2013-01-05 mozilla-central nightly (since the latter is the first in which the fix for bug 825620 appeared). That's true.

But we're still not out of the woods with the Unity plugin, because there's another bug: Even in today's mozilla-central nightly, the example from comment #0 doesn't display properly in HiDPI mode. I'll open another bug on that.

(In reply to Steven Michaud from comment #13) > I wonder if the Unity plugin changes its behavior according to which browser > it thinks it's running it. Unity has some (very few) browser specific workarounds or behaviors. But non of these should be relevant in this case, as the crash occurs before any unity code is executed, or even before dlopen() is called on the unity plugin binary. This can be verified by replacing the Unity plugin binary with any other binary, such as Flash plugin - the crash will still remain. It is caused by the lacking "WebPluginDescription" key in the Info.plist, which is probably being parsed by Firefox before it starts executing any plugin code.

(Following up comment #16) I've opened bug 829284.

Will this be fixed in 18.0.1?

(In reply to Martin Best (:mbest) from comment #19) > Will this be fixed in 18.0.1? Yes, we will be taking the patch in Bug 825620 to fix the issue here .

I've verified this on Mac OS X 10.7.x with the 18.0.1 candidate builds. The plugin now loads. This was also verified in 19.0b2. I'll mark this as fixed and verified.

per comment 21