When the print engine asks for print settings from the user, it calls nsIPrintingPromptService::ShowPrintSettings. For OS X, Windows and Linux GTK, that method blocks, as it opens a modal dialog on each platform. I don't think we can necessarily avoid the fact that GTK, the Windows SDK, and probably Cocoa all require a nested event loop in order to get print settings, but we can refactor nsPrintEngine so that the calls to those blocking native functions occur when nothing else is on the stack. Then, when those blocking calls return, we can call some other function on the nsPrintEngine to continue print execution. That's way safer than spinning a nested event loop with a bunch of printing machinery on the stack. This would also mean that the content process would not need to spin a nested event loop at all when waiting for print settings in the multi-process case.