1836720 - mozilla::gfx::PrintTargetWindows::BeginPrinting can hang the main thread on Windows in StartDocW

Status: NEW

(Core :: Graphics, defect, P2)

Description

[Jens Stutte [:jstutte]]

According to BHR.

Comment 1

[Bob Hood [:bhood]]

Observation: I just (this morning) printed a PDF attached to a Hotmail email from within Fx113.0.2, and it spun on "building preview" for almost two minutes, but it did finally return and I was able to print.

Adding this to triage for Graphics review.

Comment 2

[Timothy Nikkel (:tnikkel)]

There was some chat about this on element: it looks like the "hang" is while opening a native dialog, is that actually a user-perceived hang?

Comment 3

[Jens Stutte [:jstutte]]

My understanding is that this means the main thread is unresponsive to other events while the dialog is open. Most of the times that might be ok from a user perspective (a modal dialog is a modal dialog), but any other ongoing background things that need to pass through the main thread would be blocked, too, making the events pile up in the queue and/or make us ignore shutdown requests. A pattern like using a spinEventLoopUntilOrQuit would help to avoid this.

Comment 4

[Kelsey Gilbert [:jgilbert]]

@jrmuizel Who would know more about printing for this?

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Is this new? I expect we've had this for a very long time.

In theory it should be possible to move printing off the main thread, but it may not be easy.

The full stack for reference:

ZwUserMsgWaitForMultipleObjectsEx win32u
int MphWaitMessageEx(unsigned int,unsigned long) DUser
_ClientWaitMessageExMPH user32
KiUserCallbackDispatcherContinue ntdll
NtUserWaitMessage win32u
DialogBox2(HWND__*, HWND__*, int, int) user32
InternalDialogBox(void*, DLGTEMPLATE*, HWND__*, int64_t (*)(HWND__*, unsigned int, uint64_t, int64_t), int64_t, unsigned int) user32
DialogBoxIndirectParamAorW user32
DialogBoxIndirectParamW user32
<lambda_f5e2b7f326e4941da317d6999ba6351a>::operator() comdlg32
CFileOpenSave::Show(HWND__*) comdlg32
CommonDialogSaveAs(unsigned short const*, unsigned short const*, HWND__*, STRING_PAIR*, unsigned long, NCoreLibrary::TString*, NCoreLibrary::TString*, bool*) winspool
GetSaveFileNameDialog(void*, HWND__*, unsigned short**, unsigned short**) winspool
StartDocDlgW(void*, _DOCINFOW*) winspool
StartDocWImpl gdi32full
StartDocW gdi32
mozilla::gfx::PrintTargetWindows::BeginPrinting(nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, int, int) xul

Comment 6

[Jeff Muizelaar [:jrmuizel]]

The docs for StartDocW say:

Note 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.

Comment 7

[Jens Stutte [:jstutte]]

I do not think this is new. I do see (some) crashes that show us hanging there during shutdown, like here.

In general there seem to be crashes with this function on the stack, volume is not terribly high, though (~150 in a month).