Opening the print dialog generates Sandbox-related errors to appear in the Console app. SandboxViolation: plugin-container(80445) deny(1) mach-lookup com.apple.printtool.agent #print __agent_connection_block_invoke_2: Connection error - Connection invalid These don't appear to be related to any printing problems. A stack from the Console app shows the printtool.agent is triggered by code in content attempting to get a native page format object before the print dialog is displayed: 0 libsystem_kernel.dylib mach_msg_trap + 10 1 libdispatch.dylib _dispatch_mach_send_and_wait_for_reply + 591 2 libdispatch.dylib dispatch_mach_send_with_result_and_wait_for_reply + 45 3 libxpc.dylib xpc_connection_send_message_with_reply_sync + 154 4 PrintCore printToolAgent + 91 5 PrintCore CPLCopyDefaultPrinterName + 40 6 PrintCore OpaquePMPrintSession::SetCurrentPrinter() + 94 7 PrintCore OpaquePMPrintSession::OpaquePMPrintSession() + 464 8 PrintCore PJCCreateSession(OpaquePMPrintSession**) + 35 9 PrintCore PMCreateSession + 26 10 AppKit -[NSPrintInfo(NSInternal) _printSessionForGetting] + 43 11 AppKit -[NSPrintInfo(NSInternal) _createDefaultOrUnflattenPageFormatIfNecessary] + 183 12 AppKit -[NSPrintInfo(NSInternal) _pageFormatForGetting] + 27 13 XUL nsPrintSettingsX::InitUnwriteableMargin() + 32 14 XUL nsPrintSettingsX::Init() + 15 15 XUL nsPrintOptionsX::_CreatePrintSettings(nsIPrintSettings**) + 76 16 XUL nsPrintOptions::GetGlobalPrintSettings(nsIPrintSettings**) + 48 .. We could avoid this sandbox violation by allowing access to com.apple.printtool.agent in the content sandbox rules, but it would be better to refactor the code in content to avoid triggering the violation. The content process reads the page format information from the OS and sends it to the parent as print settings, but the parent no longer uses print settings it receives from the content process.

To clarify what refactoring should be done here: In some cases, the child process sends an nsPrintSettingsX object over to the parent. This is done when initiating a print and also when the child process calls SavePrintSettings() to instruct the parent to save print settings to prefs. However, the child never starts with a valid nsPrintSettingsX because of existing bugs. The child rebuilds the print settings each time instead of loading them from prefs. See explanation on bug 1303051 comment 28 <https://bugzilla.mozilla.org/show_bug.cgi?id=1303051#c28> for details. The parent was changed to ignore the print settings received from the child when displaying the print dialog and instead use the saved print settings from prefs. We should fix/refactor this so that we don't ever try to build an nsPrintSettingsX object in the child. When we trigger a print from the child, we should just send the information the parent needs (which is a subset of the nsPrintSettingsX) such as the document title. After the dialog is dismissed and the print is ready to proceed, the parent should be changed to just send back what the child needs to finish the remote print. On Mac, the pref print.save_print_settings is ineffective due to the above problem. After the print dialog is displayed, the parent saves the printing prefs (for example, portrait vs landscape) so that the next time the print dialog is opened, the previous selections are remembered. But after printing, the child sends a SavePrintSettings message to the parent which includes default print settings overwriting what the parent saved. From discussions with Bob Owen, our Windows printing implementation is similar in that the child process is involved with generating the print settings and sending them to the parent when it doesn't need to be. The same probably applies to Linux remote printing because e10s printing works similarly there, but that is TBD.