859655 - Printing causes main-thread hangs of multiple seconds

Status: NEW

(Core :: Printing: Output, defect)

Description

[Vladan Djeric (:vladan)]

The Telemetry chrome-hang data shows the following multi-second hang occurring frequently:

NtRequestWaitReplyPort (in wntdll.pdb)
 -> PROXYPORT::DocumentEvent(void *,void *,HDC__ *,int,unsigned long,void *,unsigned long,void *) (in wgdi32.pdb)
 -> DocumentEventEx (in wgdi32.pdb)
 -> StartDocW (in wgdi32.pdb)
 -> gfxWindowsSurface::BeginPrinting(nsAString_internal const &,nsAString_internal const &) (in xul.pdb)
 -> nsDeviceContext::BeginDocument(wchar_t *,wchar_t *,int,int) (in xul.pdb)
 -> nsPrintEngine::SetupToPrintContent() (in xul.pdb)
 -> nsPrintEngine::DocumentReadyForPrinting() (in xul.pdb)
 -> nsPrintEngine::AfterNetworkPrint(bool) (in xul.pdb)
 -> nsPrintEngine::InitPrintDocConstruction(bool) (in xul.pdb)
 -> nsPrintEngine::Observe(nsISupports *,char const *,wchar_t const *) (in xul.pdb)
 -> nsPrintProgress::DoneIniting() (in xul.pdb)
 -> NS_InvokeByIndex_P (in xul.pdb)
 -> XPC_WN_CallMethod(JSContext *,unsigned int,JS::Value *) (in xul.pdb)
 -> js::InvokeKernel(JSContext *,JS::CallArgs,js::MaybeConstruct) (in mozjs.pdb)

Comment 1

[Zack Weinberg (:zwol)]

StartDocW is documented to block for a significant period: quoting http://msdn.microsoft.com/en-us/library/windows/desktop/dd145114%28v=vs.85%29.aspx 

> ... This is a blocking or synchronous function and might not
> return immediately. How quickly this function returns depends on
> run-time factors such as network status, print server configuration,
> and printer driver implementation—factors that are difficult to predict
> when writing an application. Calling this function from a thread that
> manages interaction with the user interface could make the application
> appear to be unresponsive.

This is not the only place where printing uses Windows APIs that are synchronous and can hang the calling thread for multiple seconds.  This other note, from http://msdn.microsoft.com/en-us/library/windows/desktop/ff819274%28v=vs.85%29.aspx , is telling:

> To provide the best user experience when you print from a native Windows
> program, the program must be designed to print from a dedicated thread.
> In a native Windows program, the program is responsible for managing
> user interface events and messages. Printing operations can require
> periods of intense computation as the application content is rendered
> for the printer, which can prevent the program from responding to user
> interaction if this processing is performed in the same thread as event
> processing of the user interaction.

I'm generally of the opinion that we should be minimizing the amount of development effort we put into Windows, but our poor handling of printing on Windows is holding us back on our non-legacy platforms as well.  I am insufficiently skilled at Win32 programming to fix this myself, but I have been working on print-related stuff and would be happy to advise anyone who wants to tackle this.