Open Bug 1328975 Opened 3 years ago Updated 1 year ago

Mac e10s printing needs refactoring, causes sandbox violations to be logged


(Core :: Security: Process Sandboxing, defect, P3)

53 Branch



Tracking Status
firefox53 --- affected


(Reporter: haik, Unassigned)


(Blocks 1 open bug)


(Whiteboard: sb+)

Opening the print dialog generates Sandbox-related errors to appear in the Console app.

  SandboxViolation: plugin-container(80445) deny(1) mach-lookup

  #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 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.
See Also: → 1324610
Summary: Mac e10s printing needs refactoring, causes sandbox violations to be logged in the OS X Console App → Mac e10s printing needs refactoring, causes sandbox violations to be logged
Whiteboard: sb
Whiteboard: sb → sbmc3
See Also: → 1330643
Blocks: sb-print
Priority: -- → P3
Whiteboard: sbmc3 → sb+
Blocks: 1403260
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 <> 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.
No longer blocks: 1403260
See Also: → 1403260
See Also: → 1421957
See Also: → 1319116
You need to log in before you can comment on or make changes to this bug.