Created attachment 543646 [details] testcase ###!!! ASSERTION: Getting architecture of plugin container failed!: 'NS_SUCCEEDED(rv) && pluginContainerArchs != 0', file /Users/jruderman/trees/mozilla-central/ipc/glue/GeckoChildProcessHost.cpp, line 250
The problem is that we attempt to look up the architecture on the plugin binary with a bad path: .../NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container Note that "/Contents/MacOS/plugin-container.app" has been appended twice.
Created attachment 557055 [details] [diff] [review] fix v1.0 The assertion is coming from the child process. The problem is that we append the path to the child process bundle even if we started with the child process binary location.
pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/13b9a3f0eb42
I have verified this using the test case from the attachment on: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0 beta 4 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111127 Firefox/10.0a2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111204 Firefox/11.0a1 The process of getting the add-on worked as expected (no add-ons were found). This is the right functionality or I have to consider other aspects? Can I change the status of this bug tu Verified? Thanks.
Considering comment6, setting resolution to Verified Fixed