The IOService loads all content sniffers registered in the category manager the first time it is loaded. If a content sniffer is implemented in JS then initializing it requires the ScriptSecurityManager to load. That, in turn, requires the IOService. This recursion is not allowed and so the content sniffer fails to load properly. Not sure what to do about this. I had to reimplement my component in C++ :(
Created attachment 272406 [details] [diff] [review] patch this should fix it, and it doesn't break the content sniffer unit test, but I haven't tested yet whether it fixes the actual bug here.
Created attachment 272837 [details] test component copy to components/; starting the second app startup you'll see a security manager init assertion and no "called" dumps
Comment on attachment 272406 [details] [diff] [review] patch ok, I tested the patch and it works
Checking in netwerk/base/src/nsIOService.h; /cvsroot/mozilla/netwerk/base/src/nsIOService.h,v <-- nsIOService.h new revision: 1.64; previous revision: 1.63 done Checking in xpcom/glue/nsCategoryCache.h; /cvsroot/mozilla/xpcom/glue/nsCategoryCache.h,v <-- nsCategoryCache.h new revision: 1.2; previous revision: 1.1 done
Would be good to find a way to test this...
Comment on attachment 272406 [details] [diff] [review] patch This is a really safe fix, and this bug is causing branch extension developers a good bit of grief. Ben and I both think this should be safe to take on branch, and I'd ask us to think about doing just that...
Comment on attachment 272406 [details] [diff] [review] patch approved for 22.214.171.124, a=dveditz for release-drivers
Fixed on branch.
(In reply to comment #6) > Would be good to find a way to test this... > Did anyone find a way to test this? This is hard to verify otherwise.
For what it's worth, the extension developer who was having issues due to this has confirmed that his problem is fixed on branch. Is that good enough to verify?
Yes, that's good enough for us. Marking it...