I'm creating first mochitest-plain test in widget/tests in bug 930374. But I meet this bug which causes orange. https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=9bc46d1a711d However, preceding test, uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml launches iCal on Mac and it fails to kill iCal process at the end of the test. The evidence is the attached screenshot. At least, our window should be activated even if we fail to kill iCal. Otherwise, I think that we should disable this test on Mac. http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/tests/mochitest/handlerApps.js

I thought we had an existing bug on this iCal bustage....

How do we open iCal and why is that window different than all other windows?

Hmm, looking at the code, this is what we do: <http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsLocalHandlerApp.cpp#123> which results in a call to posix_spawnp <http://mxr.mozilla.org/mozilla-central/source/xpcom/threads/nsProcessCommon.cpp#492> which seems quite normal. Can we register webcal: with a custom protocol handler or something like that?

The intent of that code is specifically to spawn OS-native applications. I suspect the right fix is to stop using iCal in the tests and instead create a "hello world" native Mac app that shuts down appropriately. I could also imagine having the test shell out and send a "kill -9" signal to iCal or something...

(In reply to comment #4) > The intent of that code is specifically to spawn OS-native applications. I > suspect the right fix is to stop using iCal in the tests and instead create a > "hello world" native Mac app that shuts down appropriately. I could also > imagine having the test shell out and send a "kill -9" signal to iCal or > something... kill -9 sounds like a good option to me!