I'd like an env var or command-line option that would change the EM restart into just a clean app shutdown, and that would perform this shutdown even if an EM restart was not needed. That is, instead of running the app once and it maybe restarting, use of this command-line option would just register extensions and do nothing else. The use case is starting Firefox under a debugger. If we had this option (call it "--force-quit-after-EM", say), I could have a script called "runfox" that does: #!/bin/sh firefox --force-quite-after-EM && env NO_EM_RESTART=1 firefox $@ Then if I run "runfox -g" things will behave as they should: gdb won't have processes disappearing under it, and I'll be able to use, say, DOM Inspector in my debug Firefox. A similar setup would be useful for mochitest.

At least on Windows, I find that -silent works well, except for the assertions.

Oh, indeed. That works beautifully, even including assertions: env XPCOM_DEBUG_BREAK=warn ${MOZILLA_FIVE_HOME}/firefox -silent && env NO_EM_RESTART=1 ${MOZILLA_FIVE_HOME}/firefox $@ and similar for seamonkey. Sounds like this is worksforme. Thank you, Neil!

WFM per comment 2

Reopening as I believe this feature would be useful for testing certain cases.

This adds a simple check for the presence of an environment variable MOZ_NO_RESTART. When present the application will not automatically relaunch itself either from an EM/compatibility triggered restart or from the application requesting a restart. These two cases generate specific exit statuses in order for a calling app to be able to distinguish them. It also adds some support for this to the python script used for running tests so if it sees a restart signal then it will restart the app properly. It will also flag a failure if the EM attempts to restart more than twice. This change will currently not do anything as the test runner isn't changed to set the new environment variable and still retains NO_EM_RESTART for now.

Comment on attachment 309426 [details] [diff] [review] patch rev 1 As discussed on IRC, this will only catch EM restarts and not profile-selection or profile-migration restarts. I think you can catch those restarts by hooking directly to LaunchChild and using exit() or _exit() from there. I suggest a more-likely-unique error code number: how about 120?