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




2 years ago
9 months ago


(Reporter: haik, Unassigned)


(Blocks: 1 bug)

53 Branch

Firefox Tracking Flags

(firefox53 affected)


(Whiteboard: sb+)



2 years ago
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.


2 years ago
See Also: → bug 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


2 years ago
Whiteboard: sb → sbmc3


2 years ago
See Also: → bug 1330643


a year ago
Blocks: 1387560
Priority: -- → P3


a year ago
Whiteboard: sbmc3 → sb+


11 months ago
Blocks: 1403260

Comment 1

10 months ago
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.


10 months ago
No longer blocks: 1403260
See Also: → bug 1403260


9 months ago
See Also: → bug 1421957
You need to log in before you can comment on or make changes to this bug.