Bug 1432651 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

My approach here is to first make sure that whenever we store a new RemotePrintJobChild on an nsIPrintSession that we also store it on the nsPrintJob. I'll then make all the locations that get their RemotePrintJobChild from an nsIPrintSettings get it from the nsPrintJob instead. Finally we can remove all the nsIPrintSession code.

It's worth providing some background for the first step since that will probably help same time trying to figure out the validity of the change during review:

nsIPrintSession::SetRemotePrintJob is only called by nsPrintSettingsService::DeserializeToPrintSettings. That has only two callers in the child process:

  1) TabChild::RecvPrint
  2) nsPrintingProxy::ShowPrintDialog

#1 on the very next line calls nsDocumentViewer::Print (via the nsIWebBrowserPrint interface) which results in us calling into nsPrintJob::DoCommonPrint and then into #2:

  nsIPrintSession::SetRemotePrintJob
  nsPrintSettingsService::DeserializeToPrintSettings
  nsPrintingProxy::ShowPrintDialog    (only content process caller of ^)
  nsPrintJob::DoCommonPrint
  nsPrintJob::CommonPrint
  nsPrintJob::Print
  nsDocumentViewer::Print             (constructs new nsPrintJob)
  nsIWebBrowserPrint::Print
  TabChild::RecvPrint

#2 waits for a sync response from the parent and gets the returned settings (containing a new RemotePrintJobChild if one wasn't passed in due to the call coming via #1). It's only child process caller is nsPrintJob::DoCommonPrint (the settings are stored in its member printData->mPrintSettings).

So basically the RemotePrintJobChild either comes from TabChild::RecvPrint, or if the nsPrintingProxy::ShowPrintDialog came from somewhere else, the RemotePrintJobChild will be created under the nsPrintingProxy::ShowPrintDialog call.
My approach here is to first make sure that whenever we store a new RemotePrintJobChild on an nsIPrintSession that we also store it on the nsPrintJob. I'll then make all the locations that get their RemotePrintJobChild from an nsIPrintSettings get it from the nsPrintJob instead. Finally we can remove all the nsIPrintSession code.

It's worth providing some background for the first step since that will probably help save time trying to figure out the validity of the change during review:

nsIPrintSession::SetRemotePrintJob is only called by nsPrintSettingsService::DeserializeToPrintSettings. That has only two callers in the child process:

  1) TabChild::RecvPrint
  2) nsPrintingProxy::ShowPrintDialog

#1 on the very next line calls nsDocumentViewer::Print (via the nsIWebBrowserPrint interface) which results in us calling into nsPrintJob::DoCommonPrint and then into #2:

  nsIPrintSession::SetRemotePrintJob
  nsPrintSettingsService::DeserializeToPrintSettings
  nsPrintingProxy::ShowPrintDialog    (only content process caller of ^)
  nsPrintJob::DoCommonPrint
  nsPrintJob::CommonPrint
  nsPrintJob::Print
  nsDocumentViewer::Print             (constructs new nsPrintJob)
  nsIWebBrowserPrint::Print
  TabChild::RecvPrint

#2 waits for a sync response from the parent and gets the returned settings (containing a new RemotePrintJobChild if one wasn't passed in due to the call coming via #1). It's only child process caller is nsPrintJob::DoCommonPrint (the settings are stored in its member printData->mPrintSettings).

So basically the RemotePrintJobChild either comes from TabChild::RecvPrint, or if the nsPrintingProxy::ShowPrintDialog came from somewhere else, the RemotePrintJobChild will be created under the nsPrintingProxy::ShowPrintDialog call.

Back to Bug 1432651 Comment 1