Bug 1090448 - Make e10s printing work on Linux

Tricky - it looks like there's a native GTK dialog (orchestrated by nsPrintDialogGTK.cpp), and a fallback XUL printer dialog if we can't get a handle on the native stuff.

Let's do the native dialog first.

The native dialog case

So, like before, the native dialog imports some settings from an nsIPrintSettings (likely casting them to an nsPrintSettingsGTK), and then spins a modal event loop before exporting new settings.

The things the dialog seems to want to get from the nsIPrintSettings… yeah, it casts it to an nsPrintSettingsGTK, and then extracts the GtkPrintSettings* from it. Also the GtkPageSetup.

Then gets a "shrink to fit" bool, "print background colours" bool, "print background images" bool.

With those last three bools, it sets dialog checkboxes to various states based on their value. Then it sets the other settings with the GtkPrintSettings* and the same goes for the GtkPageSetup*.

So… what is a GtkPrintSettings, and can I serialize it?

http://developer.gimp.org/api/2.0/gtk/GtkPrintSettings.html#gtk-print-settings-foreach

This looks useful - I can iterate each key-value pair...

Huh… here's a snippet of code I found from here :

gtk_print_settings_foreach (settings, print_settings_add_to_key_file, key_file);

static void

}

So… so I think every key and value can be serialized to a string this way? Okay….

Pretty sure we can serialize the GtkPrinter* by just getting the name and sending it over. I'm pretty sure constructing a GtkPrinter with gtk_printer_new on the child side with that name will work.

OVER TWO MONTHS PASS

Aaaaaand we're back. This is an M5 bug now, and just hit the top of my stack. So let's get back to it.

What I'd like, ideally, is parity with our current e10s printing support for Windows and OS X. At the very least, anyhow.

So, let's get a game plan together here.

The child process asks for the print settings dialog. Ugh, it looks like the child is blocked while we wait for the settings to come back down. Not great. That's bug 1090439. Let's not worry about that just this second.

So we synchronously ask the parent for information in nsPrintingPromptServiceProxy::ShowPrintDialog.

Parent receives it in PrintingParent::RecvShowPrintDialog. Gets the nsIPrintOptions service, and creates a new nsIPrintSettings. Deserialize the default settings that came up from the child. Then we show the dialog, which blocks until it returns some value.

Then we serialize the settings we got back from the dialog into a PrintData again, and send them down to the child.

Initial work that needs to be studied is bug 1082579

https://dxr.mozilla.org/mozilla-central/source/embedding/components/printingui/ipc/PrintingParent.cpp#68

https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsPrintOptionsGTK.cpp

https://dxr.mozilla.org/mozilla-central/source/widget/windows/nsPrintOptionsWin.cpp

https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsPrintSettingsGTK.cpp

https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsDeviceContextSpecG.cpp

https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsPrintDialogGTK.cpp#126

https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsPrintDialogGTK.h

Is it good enough to just serialize the name of the printer, and find it on the content side?

Are the gtk-print-settings easily serializable? Settable?

What _exactly_ is it that GTK needs from the front-end that we don't already serialize?

Interestingly, nsPrintDialogGTK already seems to have the ability to "export" and "import" GTK-specific settings from "NS" (Netscape?) print settings structures. This code is oooooooooold.

"    /* Code to copy between GTK and NS print settings structures.

*/

"

from: https://hg.mozilla.org/mozilla-central/file/29b05d283b00/widget/gtk/nsPrintDialogGTK.cpp#l144 for ImportSettings, ExportSettings.

So let's see what Export does.

Also, let's just see "what happens" when I try to print on Linux right now. A crash? Let's find out.

Yep. A crash. I guess that's not so surprising. Probably something in RecvShowPrintDialog. Wait, no that's wrong - we successfully exit from the parent process. The problem is in the content process after we return to it.

#0  __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50

#7  0xb2cbcf22 in nsPrintEngine::Print (this=0xa5967a10, aPrintSettings=0x0, aWebProgressListener=0x0) at /media/Projects/mozilla/mozilla-central/layout/printing/nsPrintEngine.cpp:781

Here's the incriminating line in nsDeviceContextSpecG.cpp:

fmtGTK is probably nullptr. It's set earlier in that same method here:

const gchar* fmtGTK = gtk_print_settings_get(mGtkPrintSettings, GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT);

Right, so we've not properly serialized/deserialized that value.

Ok, I've added the serialize / deserialize functions to nsPrintOptionsGTK. I think this is where most of the work is going to be.

Serialization is, I think, going to be easy, but verbose. I just need to grab everything inside the GtkPrintSettings that is relevant, stuff it into the PrintData. No biggie.

Deserialization… how will that work. When I deserialize in PrintingParent, I have a newly created nsIPrintSettingsGTK that I pass in. When I deserialize in the nsPrintingPromptServiceProxy, I actually pass in the old nsIPrintSettingsGTK that we'd sent up, and have it be overwritten.

The nsPrintingPromptServiceProxy is fine. But is there anything I need to do to initialize a newly created nsIPrintSettingsGTK in the parent before I deserialize? Let's check...

Ok, on construction of an nsPrintSettingsGTK, we instantiate mPrintSettings, so that's good… ok, and someone later on, I guess, sets mGTKPrinter via SetGtkPrinter. So I need to do that too, I guess...

There are a bunch of reimplementations of getters and settings in nsPrintSettingsGTK that do reading and writing from the GtkPrintSettings - so I might be getting a bunch of serialization for free already.

Yeah, lots are freebies! Nice. The ones I don't seem to get for free, I've added to the list of things to serialize / deserialize.

There's also, I believe, straight-up accessing the mPrintSettings, so there might be even more to serialize / deserialize… let's look at where the mPrintSettings get accessed.

Huh. So we do have direct access to the mGtkPrintSettings object, and fiddling there, but really, I can't trust that Gecko is telling me everything that's being used here by the user. Really, I kinda need to serialize every damn thing that's not already done by nsPrintSettingsImpl. *sigh*. Ok, what are those things.

I'll list what I can hold inside an GtkPrintSettings, and strike out the things that we got for free because nsIPrintSettings wrapped the getters / setters and our nsPrintOptions serialization already works with them...

const gchar *      gtk_print_settings_get_printer ()

GtkPageOrientation      gtk_print_settings_get_orientation ()

void      gtk_print_settings_set_orientation ()

Remark: It looks like this is being set in a GtkPageSetup thing, but I might as well send it over as well.

void      gtk_print_settings_set_paper_size ()

Remark: Crap - GtkPaperSize is a complicated object that I'll need to serialize. :( (Actually - it turns out that it's not so bad! - read below!)

void      gtk_print_settings_set_paper_width ()

gdouble      gtk_print_settings_get_paper_height ()

void      gtk_print_settings_set_paper_height ()

gboolean      gtk_print_settings_get_collate ()

void      gtk_print_settings_set_collate ()

GtkPrintDuplex      gtk_print_settings_get_duplex ()

void      gtk_print_settings_set_duplex ()

void      gtk_print_settings_set_quality ()

void      gtk_print_settings_set_n_copies ()

void      gtk_print_settings_set_number_up ()

void      gtk_print_settings_set_number_up_layout ()

void      gtk_print_settings_set_resolution ()

gint      gtk_print_settings_get_resolution_y ()

void      gtk_print_settings_set_printer_lpi ()

GtkPrintPages      gtk_print_settings_get_print_pages ()

GtkPageRange *      gtk_print_settings_get_page_ranges ()

GtkPageSet      gtk_print_settings_get_page_set ()

void      gtk_print_settings_set_page_set ()

void      gtk_print_settings_set_default_source ()

void      gtk_print_settings_set_media_type ()

void      gtk_print_settings_set_dither ()

void      gtk_print_settings_set_finishings ()

void      gtk_print_settings_set_output_bin ()

What… what is the relationship between GtkPageSetup and GtkPaperSize?

GtkPaperSize seems to be something you can get from GtkPageSetup… and you can set a GtkPaperSize on it too with gtk_page_setup_set_paper_size. And then there's gtk_page_setup_set_paper_size_and_default_margins. Ahhhhh - a GtkPaperSize represents the default paper sizes that exist within the system. So I think I can just serialize the name, and send it over. Right? YES - I can get the name of the GtkPaperSize, and then when I instantiate one, I can pass in that name, and it'll assume the right values. Good! OH! And Paper Name is already being serialized and sent over by nsPrintSettingsImpl! \o/

So, when deserializing, I think I just need to create a custom GtkPaperSize with the name I was passed, and then set that on the GtkPageSetup.

I can use SetGtkPageSetup to save the GtkPageSetup, which contains the GtkPaperSize information, to the GtkPrintSettings.

Last piece of the puzzle, I think. What the hell is a GtkPrintBackend?

I… I don't think it matters. Instead of instantiating the GtkPrinter, I'll enumerate one until I find the one the user specified.

Roadblock :

So, new TODO: I need to make nsPrintOptionsImpl smartly serialize things that might not exist. That means coming up with some sane defaults.

No. Wait. That's too complicated. Wayyyyy to complicated. The far simpler solution is just to have nsPrintSettingsGTK default to having duplex set to GTK_PRINT_DUPLEX_SIMPLEX (which apparently means "no duplex"). Yeah, jeebus, that's way better.

Wooo - just by serializing the GTKPrinter, I got something out:

But.. I'm crashing on shutdown. I'm crashing because I'm failing an assertion:

#0  0xb770f424 in __kernel_vsyscall ()

#18 0x0804c18b in main (argc=4, argv=0xbff59b84) at /media/Projects/mozilla/mozilla-central/browser/app/nsBrowserApp.cpp:667

Note that this is happening in the parent process. I'm going to guess that this is likely our mGtkPrinter being leaked? I think so. I don't even need to initiate a print to cause this crash. I just need to open the dialog - which causes the deserialization on the parent side which refs the new printer.

OH - I might need to unref the old printer! … wait, that's not the case - nsPrintSettingsGTK::SetGtkPrinter automatically unrefs the old printer before swapping in the new one.

Let me get rid of the mGTKPrinter bits anyways to see if that helps.

Ah, it doesn't. I'm leaking somewhere else. Let's work it backwards...

Facts:

I'm going to try to use valgrind to narrow things down. Going to be slow as ass, but it seems like the best solution as opposed to guessing.

This document tells me that I need to add some stuff to my .mozconfig (--disable-jemalloc and --enable-valgrind), so I'm waiting for that to build. In the meantime,

==20134== Thread 1:

==20134== 3,575 (896 direct, 2,679 indirect) bytes in 8 blocks are definitely lost in loss record 20,610 of 21,200

==20134==

This looks like it's been around for a while! https://bugzilla.mozilla.org/show_bug.cgi?id=1129557

I'm tried to bisect and haven't found a good state - I went back to around Firefox 4.

So, decision: ignore the leak. It's not my bag, baby.

OK, attack plan:

Rename nsPrintOptionsImpl::SerializeToPrintSettings to nsPrintOptionsImpl::SerializeCommon and take default value struct.

Make nsPrintOptionsWin and nsPrintOptionsGTK use nsPrintOptionsImpl::SerializeCommon, each passing in a struct of defaults.

Serialize GtkPaperSize stuff

Deserialize it and generate custom GtkPaperSize with the same dimensions, names, etc.

Serialize GtkPageSetup stuff

When deserializing, create a new GtkPrintSettings, and set the GtkPageSetup on it with SetGtkPageSetup

Serialize all GtkPrintSettings stuff

Deserialize all of the GtkPrintSettings stuff

Deserialize the GtkPrinter by enumerating the printers until I find one with the same name

Stuff all that shit into the nsPrintSettingsGtk

GtkPaperSize (via gtk_paper_size_new_custom)

gtk_paper_size_get_name (const gchar *) - this is already serialized as paperName

gtk_paper_size_set_name (gchar *)

gtk_paper_size_get_display_name (gchar *)

gtk_paper_size_set_display_name (gchar *)

Things to serialize / deserialize:

GtkPaperSize

GtkPageSetup

GtkPrinter (already being sent over by nsPrintSettingsImpl, but needs deserialization!)

InitUnwriteableMargin? "Re-initialize mUnwriteableMargin with values from mPageSetup. Should be called whenever mPageSetup is initialized or overwritten.

GtkPrintSettings (see below)

GtkPrintSettings to make sure we transfer:

gtk_print_settings_get_orientation (enum GtkPageOrientation)

gtk_print_settings_set_orientation (enum GtkPageOrientation)

gtk_print_settings_get_paper_width (gdouble)

gtk_print_settings_set_paper_width (gdouble)

gtk_print_settings_get_paper_height (gdouble)

gtk_print_settings_set_paper_height (gdouble)

gtk_print_settings_get_collate (gboolean)

gtk_print_settings_set_collate (gboolean)

gtk_print_settings_get_quality (enum GtkPrintQuality)

gtk_print_settings_set_quality (enum GtkPrintQuality)

gtk_print_settings_get_number_up (gint)

gtk_print_settings_set_number_up (gint)

gtk_print_settings_get_number_up_layout (enum GtkNumberUpLayout)

gtk_print_settings_set_number_up_layout (enum GtkNumberUpLayout)

gtk_print_settings_set_resolution_xy (gint)

gtk_print_settings_get_resolution_x (gint)

gtk_print_settings_get_resolution_y (gint)

gtk_print_settings_get_printer_lpi (gdouble)

gtk_print_settings_set_printer_lpi (gdouble)

gtk_print_settings_get_page_set (enum GtkPageSet)

gtk_print_settings_set_page_set (enum GtkPageSet)

gtk_print_settings_get_default_source (const gchar * )

gtk_print_settings_set_default_source (const gchar * )

gtk_print_settings_get_media_type (const gchar * )

gtk_print_settings_set_media_type (const gchar * )

gtk_print_settings_get_dither (const gchar * )

gtk_print_settings_set_dither (const gchar * )

gtk_print_settings_get_finishings (const gchar * )

gtk_print_settings_set_finishings (const gchar * )

gtk_print_settings_get_output_bin (const gchar * )

gtk_print_settings_set_output_bin (const gchar * )

GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT

GTK_PRINT_SETTINGS_OUTPUT_URI

GTK_PRINT_SETTINGS_PAPER_FORMAT (set by GtkPaperSize via gtk_print_settings_set_paper_size)

GTK_PRINT_SETTINGS_PAPER_WIDTH (set by GtkPaperSize via gtk_print_settings_set_paper_size)

GTK_PRINT_SETTINGS_PAPER_HEIGHT (set by GtkPaperSize via gtk_print_settings_set_paper_size)

GtkPageSetup to make sure we transfer:

gtk_page_setup_set_paper_size_and_default_margins (GtkPaperSize) (this needs to be constructed first with the right GtkPaperSize name!)

gtk_page_setup_get_orientation (enum GtkPageOrientation)

gtk_page_setup_set_orientation (enum GtkPageOrientation)

gtk_page_setup_get_top_margin (gdouble)

gtk_page_setup_set_top_margin (gdouble)

gtk_page_setup_get_bottom_margin (gdouble)

gtk_page_setup_set_bottom_margin (gdouble)

gtk_page_setup_get_left_margin (gdouble)

gtk_page_setup_set_left_margin (gdouble)

gtk_page_setup_get_right_margin (gdouble)

gtk_page_setup_set_right_margin (gdouble)

Feedback from karlt:

I wonder why all these details need to be accessed on both the content and

browser sides. Could there be a cross-process object that is opaque on the

content side? Is there only a subset of this info that is needed by layout?

I don't have good ideas on how to deal with finding the GtkPrinter

synchronously. If it needs to pass between processes then perhaps determining

the GtkPrinter can be delayed until printing, which is already an async

process, I assume.

GtkPrintSettings is basically a hash table of strings keyed by strings. All

the accessor methods just convert between string and the particular format.

The keys aren't necessarily limited to the strings with GTK_PRINT_SETTINGS\_\*

defines. "The predefined keys try to use shared values as much as possible so

that moving such a document between systems still works", but I suspect

special printer backends might use other values. However, strings are

reasonably easy to serialize anyway, I assume, so, if this needs to be passed

between processes, then I suspect it would be simpler to use

gtk_print_settings_foreach() and gtk_print_settings_set(), with an array of

pairs of strings in PrintData.

I haven't yet looked at how GtkPageSetup and GtkPaperSize are used. I wonder

why the GtkPaperSize doesn't come from gtk_print_settings_get_paper_size().

I think we need to do whatever is necessary to avoid running arbitrary events in DeserializeToPrintSettings(). Nested event loops are evil. They unroll only in FILO order, and they surprise callers who don't expect the world to change while they weren't watching.

Is it necessary to pass the printer between content and browser processes? Is it the printer selection or the printing that happens in the content process? Could they both happen in the browser process?

Replace custom GTK things in PPrinting.ipdl's PrintData with an array of string pairs.

Ok, create a struct with key and value nsCStrings, and then have PrintData hold onto an array of those structs.

Serialize GtkPrintSettings back and forth by iterating the keys / values.

Find a way of getting at the GtkPrinter without enumerating them

Grawrrr,  GtkPrintBackend is woefully documented. But I think I can make this work...

I can emulate enumerate_printers, like this:

void

gtk_enumerate_printers (GtkPrinterFunc func,

gpointer data,

GDestroyNotify destroy,

gboolean wait)

{

PrinterList *printer_list;

GList *node, *next;

GtkPrintBackend *backend;

printer_list = g_new0 (PrinterList, 1);

printer_list->func = func;

printer_list->data = data;

printer_list->destroy = destroy;

if (g_module_supported ())

printer_list->backends = gtk_print_backend_load_modules ();

if (printer_list->backends == NULL)

{

free_printer_list (printer_list);

return;

}

for (node = printer_list->backends; node != NULL; node = next)

{

next = node->next;

backend = GTK_PRINT_BACKEND (node->data);

if (list_printers_init (printer_list, backend))

return;

}

if (wait && printer_list->backends)

{

printer_list->loop = g_main_loop_new (NULL, FALSE);

GDK_THREADS_LEAVE ();

g_main_loop_run (printer_list->loop);

GDK_THREADS_ENTER ();

}

}

Then don't forget to g_list_free(printer_list->backends);!

Evernote screwed up the formatting, but you get it. Basically I create a backend list, iterate that list, and for each backend, I can use gtk_print_backend_find_printer.

As soon as I find one that matches, I bail out. Easy… peasy… I think. *sigh*, why didn't GTK just supply this.

Graaarwwrwaeraera fuck.

The gtk_print_backend stuff isn't accessible. It's all private. I can't use this stuff! :(((((

karlt suggests looking into whether or not we can delay printer assignment until the very end of printing, when things are already asynchronous. I'll look into that next.

So here I am again, ass deep in nsPrintEngine.cpp.

Ok… I think this will work. In sum:

Make it so that nsDeviceContextSpecG does not need to know about the GtkPrinter until EndDocument is called, at which time it asynchronously queries for the right printer, and sends the job off.

This will mean ripping out some old stuff that reads the mGTKPrinter from the nsIPrintSettings, and instead sending that information through nsPrintSettingsGTK instead.

Add SupportsPDF getter and setter to nsPrintSettingsGTK

Set the SupportsPDF setter in nsPrintDialogWidgetGTK::ExportSettings

In the Serialization/Deserialization methods, get and set SupportsPDF

Change the code in nsDeviceContextSpecGTK::GetSurfaceForPrinter to use SupportsPDF instead of mGtkPrinter.

Make nsDeviceContextSpecGTK::EndDocument asynchronously fetch the printer if one doesn't already exist

Move the creation of the GtkPrintJob out of BeginDocument to EndDocument

file:///Users/mikeconley/Projects/gtk2-html-2.24.25/GtkPrintJob.html#GtkPrintJobCompleteFunc

void

(*GtkPrintJobCompleteFunc) (GtkPrintJob *print_job,

gpointer user_data,

GError *error);

file:///Users/mikeconley/Projects/gtk2-html-2.24.25/GtkPrinter.html#GtkPrinterFunc

gboolean

(*GtkPrinterFunc) (GtkPrinter *printer,

gpointer data);

static void job_complete we'll do the same thing.

printer_enumerator

In nsPrintOptionsGTK.h remove PPrinting.h, and forwards declare the PrintData struct instead

Either remove the using namespace in nsPrintOptionsGTK.cpp, or actually make use of it when referring to PrintData

Try calling SetGtkPrintSettings after deserialization, in DeserializeToPrintSettings, and remove the SetDuplex inside the nsPrintSettingsGTK Initializer

Get SerializeGTKPrintSettingsToPrintData out of the nsPrintSettingsGTK header

Remove unused gtkPageSetup and gtkPaperSize from deserialization method

In DeserializeToPrintSettings, instead of re-using the GtkPrintSettings, destroy it and create a new one.

Why isn't the printer name getting sent down to the content process properly?

The problem was that the printer name was getting wiped out, since we rely on the mGtkPrintSettings inside nsIPrintSettings to hold on to the printer name. After deserializing a bunch of stuff in nsPrintOptionsGTK::DeserializeToPrintSettings, I was chucking out the GtkPrintSettings inside nsIPrintSettings and replacing it with one that just had the GTK-specific settings set on it.

The solution was to create the new GtkPrintSettings and set it on the nsIPrintSettings _before_ attempting to deserialize the PrintData from the parent. That way, we can properly get the printer name and enumerate/find the target printer.

In nsDeviceContextSpecGTK, make the printer enumerator and start print job methods private or protected. Probably private.

Remove acceptsPDF bool from PrintData, and have nsPrintDialogGTK set the output format instead. So basically, stash this value in the output format.

Move the printer enumerator in nsDeviceContextSpecGTK into a runnable

Replace nsCOMPtr<nsIPrintSettings> mPrintSettings with nsCOMPtr<nsPrintSettingsGTK> mPrintSettings in nsDeviceContextSpecGTK

"NS_ConvertUTF16toUTF8 is a class holding an extra copy of the string, so please use mTitle.Truncate() and AppendUTF16toUTF8(aTitle, mTitle)"

Rename KeyValue to CStringKeyValue?

Address dw-dev's feedback from bug 1088070

EndDocument() is called from the nsPrintData destructor, so I don't think we

can assume that this is a safe place to run the event loop. Instead dispatch

an event that will call gtk_enumerate_printers(). There could be issues with

asynchronicity if GetSurfaceForPrinter() calls are repeated after

EndDocument(), so either assert this doesn't happen, or pass mSpoolFile

to the event.

Do the above… maybe ask karlt what he means here.

Figure out better naming inside nsDeviceContextSpecGTK? mPrintSettingsGTK vs mGtkPrintSettings is crazy confusing. No longer needed since I just have the one mPrintSettings now.

Flesh out comment in nsDeviceContextSpecGTK::EndDocument clearing up what the hell is going on

TODO

Stow GTK-specific print settings inside PrintData in PPrinting.ipdl

Set print.enable_e10s_testing flag to true for Linux

Handle the XUL dialog case (this appears to be mostly unused code…)

Yes! r+ from karlt! Now a try push for safety...

Amusement

https://twitter.com/snorp/status/562999621484838914

https://gist.github.com/eed3si9n/3920236