Open Bug 1596307 Opened 3 years ago Updated 3 years ago

Problems with closing GTK print dialog

Categories

(Core :: Widget: Gtk, defect, P2)

Unspecified
Linux
defect

Tracking

()

People

(Reporter: karlt, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Scenario A:

  1. Open two Firefox windows.
  2. From window 1, open a print dialog (Ctrl+P).
  3. From window 2, open another print dialog.
  4. Click "Cancel" in the dialog from step 2.

Expected: Dialog closes.

Actual: Dialog does not close until "Cancel" is also clicked on the second dialog.

Scenario B:

  1. Open two Firefox windows.
  2. From window 1, open a print dialog (Ctrl+P).
  3. From window 2, quit the application (Ctrl+Q).

Expected: Application quits.

Actual: Print dialog remains open.

Scenario B is what sometimes happens when the web-platform test /printing/print-microtask-after-navigate.html times out and nsAppStartup::Quit() is called during gtk_dialog_run() from nsPrintingPromptService::ShowPrintDialog(). "Hit MOZ_CRASH(Shutdown hanging before starting.)" is reported before the first failure of e.g. https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=275885234&repo=try&lineNumber=41908

The close on response closes the dialog even with another nested event loop
prevents nsIPrintDialogService::Show() from returning.

The changes here are similar to those made for nsFilePicker when pretending to
run the dialog synchronously.
https://hg.mozilla.org/mozilla-central/rev/d066131af975

This reorganization of code should be more suitable for a future asynchronous
behavior.

Blocks: 1599952
No longer blocks: 1565956
You need to log in before you can comment on or make changes to this bug.