1145916 - printing multiple copies doesn't work with e10s

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Chris AtLee [:catlee]]

If I print from e10s (which works!), I only ever get 1 copy regardless of how many copies I request in the print dialog.

If I print exactly the same PDF in non-e10s, the # of copies field is respected.

Comment 1

[Tracy Walker [:tracy]]

Chris, this wfm on Mac.  Is there any particular document this fails on or is it happening when printing any page?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

I would imagine this would need to be tested on a Linux machine to reproduce catlee's experience - the OS X printing machinery that we're using for e10s is dramatically different from the one used for Windows and Linux.

Comment 3

[Chris AtLee [:catlee]]

Yeah, it's not any specific page. For example, I just tried printing off 2 copies of page 1 of this bugzilla page, and only got one copy.

Comment 4

[Tracy Walker [:tracy]]

I am able to reproduce this in a clean profile on Ubuntu VM  (actually surprised printing worked at all), only one copy printed, when I chose to make 2 copies.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

So I can easily reproduce this bug.

What concerns me is that I can also reproduce it even outside of e10s.

So I can't seem to print multiple copies ever in my Ubuntu VM, e10s or not.

This appears to be the case even with the stock version of Firefox in my VM, which is 28.

I dug in with a debugger, and it looks like we're serializing/deserializing the n-copies setting properly on the GtkPrintSettings...

Needinfo'ing people who use Linux - does printing multiple copies work ever? e10s or not?

Comment 6

[George Wright (:gw280) (needinfo me!)]

On my Fedora 21 workstation, I can print multiple copies in non-e10s on the latest Linux nightly. e10s only prints one copy.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I was also able to print two copies (of the bugzilla front page) using a non-e10s window in Linux. Did not try with e10s.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Ah, this would explain it - my PDFWriter printer driver that I've been using on my host machine doesn't seem to care about multiple copies. Probably rightly so.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Ok, I can reproduce this using the XCode Printer Simulator.

What's weird is that we're correctly setting the n-copies on the GtkPrintSettings... so I'm missing something, obviously. Digging into what that might be.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Attachment: MozReview Request: Bug 1145916 - [e10s] Defer starting a GTK Print Job during printer enumeration until the next tick. r?karlt

Bug 1145916 - Wait until we've finished enumerating the printers before starting a print job on Linux/GTK. r?karlt

Before, we were calling nsDeviceContextSpecGTK::StartPrintJob within the
gtk_enumerate_printers callback function. This was causing the GTK printing
backend to get confused about what the capabilities of the selected printer
were when running in the content process. This moves the call to StartPrintJob
outside of the gtk_enumerate_printers callback.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Hey catlee, if you feel like testing out a try build with this patch, I've pushed one to https://treeherder.mozilla.org/#/jobs?repo=try&revision=75c97648e268. Mind seeing if you can get multiple print outs with it with e10s enabled?

Comment 12

[Karl Tomlinson (:karlt)]

Comment on attachment 8639521 [details]
MozReview Request: Bug 1145916 - [e10s] Defer starting a GTK Print Job during printer enumeration until the next tick. r?karlt

https://reviewboard.mozilla.org/r/14209/#review12859

The code here doesn't match the comments, but I don't have enough information to know which approach is necessary.

::: widget/gtk/nsDeviceContextSpecG.cpp:279
(Diff revision 1)
> +      // Bug 1145916 - attempting to kick off a print job with the enumerator
> +      // still on the stack will result in the printer backend misunderstanding
> +      // what the capabilities of the printer are. We sidestep this by
> +      // deferring the print to the next tick of the event loop.
> +      nsCOMPtr<nsIRunnable> event =
> +        NS_NewRunnableMethod(spec, &nsDeviceContextSpecGTK::StartPrintJob);
> +      NS_DispatchToCurrentThread(event);

What makes you think that it is the enumerator on the stack causing the problem?

Dispatching the event doesn't necessary mean that it runs after the enumerator finishes because the enumerator runs the event loop.
Dispatching an event is much better than waiting for the enumerator to finish, because that would mean waiting for network searches to time out.

However, identifying the cause of the problem will determine the appropriate solution.

Comment 13

[Chris AtLee [:catlee]]

Yup, the try build works for me!

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8639521 [details]
MozReview Request: Bug 1145916 - [e10s] Defer starting a GTK Print Job during printer enumeration until the next tick. r?karlt

Bug 1145916 - [e10s] Defer starting a GTK Print Job during printer enumeration until the next tick. r?karlt

Before, we were calling nsDeviceContextSpecGTK::StartPrintJob within the
gtk_enumerate_printers callback function as soon as we found the printer
we wanted to print from. This was causing the GTK printing backend to get
confused about what the capabilities of the selected printer were when running
in the content process, due to https://bugzilla.gnome.org/show_bug.cgi?id=753041.
This moves the call to StartPrintJob to the next tick of the event loop.

Comment 15

[Karl Tomlinson (:karlt)]

Comment on attachment 8639521 [details]
MozReview Request: Bug 1145916 - [e10s] Defer starting a GTK Print Job during printer enumeration until the next tick. r?karlt

https://reviewboard.mozilla.org/r/14209/#review12997

Thanks for filing the GTK bug too.

Comment 16

[Mike Conley (:mconley) (:⚙️)]

url:        https://hg.mozilla.org/integration/mozilla-inbound/rev/9e625ab16ddc68f249ebd5ea40d124a434b80ed3
changeset:  9e625ab16ddc68f249ebd5ea40d124a434b80ed3
user:       Mike Conley <[e-mail]>
date:       Mon Jul 27 17:11:46 2015 -0400
description:
Bug 1145916 - [e10s] Defer starting a GTK Print Job during printer enumeration until the next tick. r=karlt

Before, we were calling nsDeviceContextSpecGTK::StartPrintJob within the
gtk_enumerate_printers callback function as soon as we found the printer
we wanted to print from. This was causing the GTK printing backend to get
confused about what the capabilities of the selected printer were when running
in the content process, due to https://bugzilla.gnome.org/show_bug.cgi?id=753041.
This moves the call to StartPrintJob to the next tick of the event loop.

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9e625ab16ddc

Comment 18

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bugnotes

http://people.mozilla.org/~mconley2/bugnotes/bug-1145916.html