Created attachment 543646 [details]
###!!! ASSERTION: Getting architecture of plugin container failed!: 'NS_SUCCEEDED(rv) && pluginContainerArchs != 0', file /Users/jruderman/trees/mozilla-central/ipc/glue/GeckoChildProcessHost.cpp, line 250
Created attachment 543647 [details]
Created attachment 543648 [details]
The problem is that we attempt to look up the architecture on the plugin binary with a bad path:
Note that "/Contents/MacOS/plugin-container.app" has been appended twice.
Created attachment 557055 [details] [diff] [review]
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
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?
Considering comment6, setting resolution to Verified Fixed