firefox doesn't use the gnome print dialog

[mon]

The title says it all. Also, I think every app (at least in main) should use the
standard gnome dialogs (including the printing one).

[Brendan-mozilla (brendan-mozilla)]

bryner says he'll take this, fwiw.

/be

[Roland-mainz (roland-mainz)]

I am not sure whether this can really be implemented without loosing existing
functionality (e.g. per-printer options and defaults) and/or rewrite parts of
both Mozilla and the Gnome Print dialog.

For Mozilla we would have at least to rewrite the current "PrinterFeatures" hack
(which is used to store the per-printer capabilities (supported "features" and
paper sizes, plex modes, resolutions, orientations, etc.)) with
nsIPrinterFeatures (e.g. a normal API instead of the prefs hack, this is bug
136058) and hook-up code to feed that information to the Gnome print dialog (and
then work around the bugs in the Gnome print dialog).

I am not sure whether spending huge amounts of work into this is wise (if you
still want to do this please consult me before starting the work) ... the
benefit isn't great and we still would not get rid of the XUL print dialog since
it is used by OS/2 and the Xlib port, too.

[Otaylor-redhat (otaylor-redhat)]

- It's possible to use the gnome-print dialog and then dump a
  postscript file to it. The gpdf code is an example of doing
  this. So, this is generally very feasible without the
  dependency on bug 192999.

- Capabilities like duplex, etc, can be queried from the
  gnome-print dialog. The set of options supported by the
  gnome-print dialog has a few things not supported by
  mozilla so there would likely have to be a bit of extension
  of the mozilla printing code for optimum integration.
  The main thing I saw here was the ability to do non-collated
  multiple copies. (1,1,2,2 instead of 1,2,1,2)

Cheerleading: this would be a huge win for users; unlike the
XUL dialog, the gnome-print dialog properly interacts
with CUPS on the system to list printers and be aware of the
particular options available on those printers. Plus, the
consistency would be wonderful to have.

[Roland-mainz (roland-mainz)]

<email address hidden> wrote:
> - It's possible to use the gnome-print dialog and then dump a
> postscript file to it

That's not enougth for Mozilla. Last time I checked it was not possible to
disable/enable or change single items like "orientation", "print command",
"paper size" etc. dynamically (e.g. per-printer) from within Mozilla code,
something the current XUL print and print job options dialog can do. And this
and other small "nits" are requirements before the Gnome print dialog can be
used.

[Otaylor-redhat (otaylor-redhat)]

What's the user feature under discussion here ... remembering your options
per-printer when selecting between multiple printers?

Obviously, different users have different requirements, but I really
can't see why remembering print options per-printer is a web-browser
required feature, as opposed to a feature that you'd like to have
in general.

(I must be using an old version of the XUL dialog, since my XUL dialog
doesn't even let me *set* the printer other than by passing options
to LPR...)

[Roland-mainz (roland-mainz)]

<email address hidden> wrote:
> What's the user feature under discussion here ... remembering your options
> per-printer when selecting between multiple printers?

I wasn't thinking about that. Mozilla allows that a print driver can teach the
print dialog about what the driver within Mozilla, the printer and the site
policy supports and what not.
For example: If you have a poster printer (e.g. DIN-A0 output format) you really
do not want to allow people to print DIN-A4 on it, right ?

> Obviously, different users have different requirements, but I really
> can't see why remembering print options per-printer is a web-browser
> required feature, as opposed to a feature that you'd like to have
> in general.

See my comment above. The Gnome print dialog cannot be restricted to the set of
options supported by the driver or printer - and feeding the driver or printer
with unsupported options or invalid option combinations will only cause havoc.
Same applies to site policies - admins may want to restrict the available
options for some reason (... continuing my example above... we could buy many
many Sun workstations from the money which is currently spend for the
"accidential" DIN-A4 printouts on our DIN-A0 poster printers).

> (I must be using an old version of the XUL dialog, since my XUL dialog
> doesn't even let me *set* the printer other than by passing options
> to LPR...)

You're likely using one of the RedHat builds of Mozilla. Get an "official" build
from mozilla.org and install the Xprint RPM from http://xprint.mozdev.org/
(don't do that on Debian/Mandrake/etc., the Xprint server is there installed
already by default) and you'll see what I mean.

[Roland-mainz (roland-mainz)]

<email address hidden>:
Instead of using the native Gnome print dialog - what about making the current
XUL print dialog more looking like the Gnome print dialog ? That would be much
easier AFAIK...

[Mpgritti (mpgritti)]

> I wasn't thinking about that. Mozilla allows that a print driver can teach the
> print dialog about what the driver within Mozilla, the printer and the site
> policy supports and what not.

Printer capabilities: if I get Owen correctly the gnome print dialog already
deal with it via CUPS, no need for mozilla to worry.

Driver capabilities: if we extend mozilla postscript driver to support all gnome
print capabilities what sort of problems you expect ?

Site policy: could you point me to docs or code where the possible policies are
defined ?

I dont think it's useful to make the gnome print support all possible
combinations of mozilla drivers but rather to use one of the mozilla drivers
(postscript with an intermediate file could be the easier solution) to be able
to print through gnome print.

[Martin Kretzschmar (martink)]

Owen wrote: "It's possible to use the gnome-print dialog and then dump a
postscript file to it. The gpdf code is an example of doing this."

The gpdf code was just stolen from Chris Lahey's galeon patch from Ximian Desktop 2.

I can't remember adding anything interesting on top of that in the gpdf
gnome-print dialog code.

[Dvschweiger (dvschweiger)]

(In reply to comment #3)
> - Capabilities like duplex, etc, can be queried from the
> gnome-print dialog. The set of options supported by the
> gnome-print dialog has a few things not supported by
> mozilla so there would likely have to be a bit of extension
> of the mozilla printing code for optimum integration.
> The main thing I saw here was the ability to do non-collated
> multiple copies. (1,1,2,2 instead of 1,2,1,2)

XPrint supports duplex, simplex, etc, from the Mozilla print dialog. What is the
gain here?

> Cheerleading: this would be a huge win for users; unlike the
> XUL dialog, the gnome-print dialog properly interacts
> with CUPS on the system to list printers and be aware of the
> particular options available on those printers. Plus, the
> consistency would be wonderful to have.

CUPS, LPRng, etc, are supported by XPrint, too. Again what is the gain here?

[Dvschweiger (dvschweiger)]

(In reply to comment #8)
> Driver capabilities: if we extend mozilla postscript driver to support all gnome
> print capabilities what sort of problems you expect ?
Extending the mozilla postscript driver is useless, many Linux distributions
already build without it and they do not care about that code - too buggy, too
insecure. XPrint printing has proven to be the better print solution

[Mpgritti (mpgritti)]

The target of this bug, together with 192999, is to integrate mozilla printing
with gnome-print. Gnome print is composed of a frontend (libgnomeprintui) and a
backend (libgnomeprint). To be able to use the dialog (and his functionalities,
it's not just matter of look and feel) you have to use the backend to do the
actual print.
Now there are two ways to use this backend. Dump it a poscript file or add
gfx/src/gnomeprint (bug 192999).
Using the native dialog you gain consistent look and feel, consistent
interaction, functionalities (for example proper interaction with CUPS owen
mentioned)

[Chofmann (chofmann)]

any chances of getting something working by 1.8a?

[Roland-mainz (roland-mainz)]

chris hofmann wrote:
> any chances of getting something working by 1.8a?

Not unless the Gnome print dialog itself gets some enhanchements. It's still a
far far way from integrating it into Mozilla without loosing lots of
functionality.

[Roland-mainz (roland-mainz)]

<email address hidden> wrote:
> Using the native dialog you gain consistent look and feel, consistent
> interaction, functionalities

What do you want exactly ? Working, usefull functionality or a "consistent look
and feel" where half the functionality is not working ?

> (for example proper interaction with CUPS owen mentioned)

What about platforms or Linux distributions which do not use CUPS ? Do you just
"ignore" them with the comment "you have to use CUPS" or will you support them,
too ?

[Roland-mainz (roland-mainz)]

<email address hidden> wrote:
> > I wasn't thinking about that. Mozilla allows that a print driver can teach
> > the
> > > print dialog about what the driver within Mozilla, the printer and the
> > site policy supports and what not.
>
> Printer capabilities: if I get Owen correctly the gnome print dialog already
> deal with it via CUPS, no need for mozilla to worry.

Erm... what about platforms which do not have CUPS ? And the way how CUPS
handles the way is very very incomplete.

> Driver capabilities: if we extend mozilla postscript driver to support all
> gnome print capabilities what sort of problems you expect ?

See David Schweigers's comment #11 about the mozilla postscript driver. I am not
sure whether it is a bright idea to extend that code and wallpaper another "fix"
on top of it. I already said a couple of _years_ (at least two years per bug
119491 comment #15) ago that the the postscript print module has very serious
design problems and should be re-done from scratch.
And nothing changed since that except braindead wallpapering over bugs.

> Site policy: could you point me to docs or code where the possible policies
> are defined ?

I mean "site policies" as described in the original CDEnext docs (they're based
on the ISO print stuff) - basically you have a way to restrict, extend or
override certain printer attributes without the need to change the printer
description (such as a PPD). A basic example is to have a rule which defines
that a certain set of printers is only allowed to print DIN-A4 in the main tray
(and the user cannot override that locally - the rules are set on the server
side).

> I dont think it's useful to make the gnome print support all possible
> combinations of mozilla drivers but rather to use one of the mozilla drivers
> (postscript with an intermediate file could be the easier solution) to be able
> to print through gnome print.

There is the "minor" problem that Xprint doesn't output PostScript files (unless
you print to a file), the jobs are generated on the Xprint server side (which
can be on another box) - the local application don't see any PostScript data at
all (which is very usefull for applications running on handhelds since all the
heavywheight stuff is done on the server side).

[Mpgritti (mpgritti)]

> What do you want exactly ? Working, usefull functionality or a "consistent look
> and feel" where half the functionality is not working ?

I want mozilla to support the limited set of functionalities of the GNOME print
system, I dont need more than that. If gnome print doesnt support a feature
there is not much value for GNOME users to have it available in the browser
(unless it's a browser specific feature).
It's more important to be able to interact consistently with the print system.

Right now we are using two different print systems in GNOME and mozilla. That
cause differences in the user interface and, more importantly, it adds
complexity to the conceptual model the user build about the desktop print
system. That's a learning cost for the majority of GNOME users, while CDEnext
site policies would be useful to a minority (and what would they gain anyway if
mozilla is the only desktop application to support them ?).

> What about platforms or Linux distributions which do not use CUPS ? Do you just
> "ignore" them with the comment "you have to use CUPS" or will you support them,
> too ?

I'm not advocating to discontinue xprint support or the XUL dialog,
distributions that likes can continue to use it.

I just want using gnome printing system to be one of the options. Ideally we
would support libgnomeprint as backend and libgnomeprintui as frontend. Though
libgnomeprint drawing api is probably going to be deprecated (see
http://bugzilla.gnome.org/show_bug.cgi?id=141241) so adding a backend could be
waste of time.

On the long time the situation is pretty clear to me. GNOME and mozilla should
be able to use the same drawing api (Cairo?). (Obviously mozilla could continue
to support different backends if desired). Then supporting the remaining part of
libgnomeprint(ui) would be easy.

On the short time we can just try to hide the print system differences to the user:

1 reimplementing libgnomeprintui dialog in XUL
2 using libgnomeprint just as a transport mechanism and libgnomeprintui native
dialog.

In any case I think the libgnomeprintui GUI should be split in a setup and a
print part. That seem more sane and would integrate better with mozilla. I'll
see if I can get someone to do it.

To me the pro of 2 are:

- we start to work on an unified user interface, rather then maintaining a fork
and having to sync it
- we are using gnome print for most of the work so it would probably result in
better integration
- we get nearer to the long term goal, only drawing api is left

The con is that we would have to use the postscript backend, which is apparently
a mess.

I think 1.8a target is not realistic unfortunately. I propose to approach the
problem this way.

1 Separate print and setup in libgnomeprintui
2 Make a list of the remaining incosistencies between XUL and native dialog
3 See if it's possible to fix these and how much work would be compared to use
the native dialog

I can deal with 1 and 2. I'll probably need some help on 3.

In the mean time we should really look at using a common drawing api on the long
run. I'd open a bug about it and cc GNOME/mozilla maintainers.
At the moment gnome printing system is not fully defined. That's a...

[Mpgritti (mpgritti)]

> There is the "minor" problem that Xprint doesn't output PostScript files (unless
> you print to a file), the jobs are generated on the Xprint server side (which
> can be on another box) - the local application don't see any PostScript data at
> all (which is very usefull for applications running on handhelds since all the
> heavywheight stuff is done on the server side).

I fear we are still not on the same page here, probably my fault in explaining
it. What I ideally want is:

--enable-xprint
--enable-gnomeprint

When gnomeprint is enabled we could also use the native print dialog, when
xprint is enabled we would use the XUL one.
I dont think there is interest to make libgnomeprintui a generic dialog that can
be used by different print systems.

[Christian Biesinger (cbiesinger)]

(In reply to comment #18)
> When gnomeprint is enabled we could also use the native print dialog, when
> xprint is enabled we would use the XUL one.

what if both are enabled? or is that not possible?

[Chofmann (chofmann)]

yeah, I guess one question is could both printing dialogs, and backends be
available a runtime and enabled via a pref (hidden?). That would allow both
distributors and users to make the selection about what printing features they
need until we get both to the state of comparable features.

I'm pretty sure that for the linux desktop get wide enterprise and business
deployment things page orientation (portrait and landscape) and paper size
controls are going to be required. Mozilla and open office are going to need
that feature for producing spreadsheets, wide tables, powerpoint like preso's
and legal docs. We need to figure out how to get those on the gnome roadmap if
they aren't there now.

it would be great if someone could go down the list of features available in the
 XUL based print dialog, the gnome print dialog, the open office print dialog,
and maybe m$ office print dialogs to make sure the gnome print dialog and
supporting backend is on track all the competive features it needs if it doesn't
have them already...

I think it would be really helpful to have a clear view of that to move forward
and an accurate and up to date chart might look something like...

                      moz-xul gnome open-office office

 page orientation x
 page size x
 feature c
 feature d
 ...
 ...

can someone volenteer to put that together with some of the data that is
scattered among the comments in this bug and a look at the latest versions?

[Mpgritti (mpgritti)]

(In reply to comment #20)
> yeah, I guess one question is could both printing dialogs, and backends be
> available a runtime and enabled via a pref (hidden?). That would allow both
> distributors and users to make the selection about what printing features they
> need until we get both to the state of comparable features.

Yeah, that sounds feasible to me.

> moz-xul gnome open-office office
>
> page orientation x
> page size x
> feature c
> feature d
> ...
> ...
>
> can someone volenteer to put that together with some of the data that is
> scattered among the comments in this bug and a look at the latest versions?

Yeah, I'll see what I can do. In general I dont expect gnome print to lack
important features and I'm sure we can put them on GNOME roadmap if there are.

What worries me most atm is the drawing api business, but let's deal with things
one at a time.

[Chofmann (chofmann)]

thanks marco. does anyone know what evolution uses? the UI seems to have a
pretty broad/good set of UI printing features along the lines that apps like
mozilla and OO might need.

[Mpgritti (mpgritti)]

Evolution uses gnome print. (Other apps that use gnome print are gnumeric and gedit)

[Roland-mainz (roland-mainz)]

<email address hidden> wrote:
> > What do you want exactly ? Working, usefull functionality or a "consistent
> > look and feel" where half the functionality is not working ?
>
> I want mozilla to support the limited set of functionalities of the GNOME
> print system,
> I dont need more than that. If gnome print doesnt support a feature
> there is not much value for GNOME users to have it available in the browser
> (unless it's a browser specific feature).

The Gnome print dialog can easily be extended to match the current features in
the Mozilla XUL/CDEnext/Windows dialogs... that's not hard... :)
I am willing to cooperate here and help marco with some specs etc. to make the
Gnome print dialog more flexible (e.g. that it can support more than one print
system - the CDEnext and KDE print dialogs are already able to do that since
years...).

> Right now we are using two different print systems in GNOME and mozilla. That
> cause differences in the user interface and, more importantly, it adds
> complexity to the conceptual model the user build about the desktop print
> system. That's a learning cost for the majority of GNOME users, while CDEnext
> site policies would be useful to a minority (and what would they gain anyway
> if mozilla is the only desktop application to support them ?).

The site policies (and other features like autoconfiguration) aren't
CDEnext-specific, they are coming from the Xprint side (most of the major design
documents about Xprint were written for the CDEnext project so please forgive me
when I start to mix both terms here wildly), so far this means Mozilla, Motif2,
Lesstif, OO and Qt-based applications can employ these features.

[snip]
> On the long time the situation is pretty clear to me. GNOME and mozilla should
> be able to use the same drawing api (Cairo?). (Obviously mozilla could
> continue to support different backends if desired)

Well, there is actually no need to make an extra Cairo _backend_ (we may better
put it somewhere in the _middle_ :) ... the Xprint server side supports the
OpenGL API and allowes to plug-in PostScript code fragments, too - so either
native Cairo-->OpenGL-->Xprint will work or those parts of a document (like SVG
plugins) which need it can generate PostScript code fragments (assuming the
destination PDL allows PS embedding, otherwise the OpenGL path should be used
(which is better anyway since it can support transparency)).

> Then supporting the remaining part of libgnomeprint(ui) would be easy.
>
> On the short time we can just try to hide the print system differences to the
> user:
>
> 1 reimplementing libgnomeprintui dialog in XUL
> 2 using libgnomeprint just as a transport mechanism and libgnomeprintui native
> dialog.

[1] is much easier for now, otherwise we will have do deal with the internals of
the mozilla print settings system and that's something which can cause _lots_ of
bugs - the code has become an horrible minefield and doing changes there usually
requires testing against the last 10 closed bug reports in that area... ;-(

BTW: When touching the XUL print dialog we have to sync with the OS/2 people
since they use the dialog, too.

> In any case I think the libgnomepr...

[Chofmann (chofmann)]

Created an attachment (id=148229)
xul/gnome/office feature comparison

[Roland-mainz (roland-mainz)]

chris hofmann wrote:
> Created an attachment (id=148229)
> xul/gnome/office feature comparison

That chart is incomplete. The Mozilla XUL dialog has "plex mode" ("simplex",
"duplex", "tumble" and custom attributes), "paper source" and "find printerr"
capabilities when Xprint is used ("orientation" is in available in the "page
setup" dialog).

[Roland-mainz (roland-mainz)]

Created an attachment (id=148236)
Mozilla-XUL/Gnome/Office feature comparison

Updated chart, on demand I can add CDEnext and KDE dialogs, too.

[Mpgritti (mpgritti)]

> > In any case I think the libgnomeprintui GUI should be split in a setup and a
> > print part. That seem more sane and would integrate better with mozilla. I'll
> > see if I can get someone to do it.

See the comparation chart. Some features in mozilla are in the Page Setup
dialog, and they are in the Print dialog for gnome print. That's an incosistency
we need to deal with.

[Piers Cornwell (piers-gnome)]

Screenshots of various print dialogs for Firefox/Win, Mozilla/Linux, Internet
Explorer/Win and Gnumeric (libgnomeprint[ui]):

http://www.sparknet.pwp.blueyonder.co.uk/print/print.html

[Mpgritti (mpgritti)]

> The Gnome print dialog can easily be extended to match the current features in
> the Mozilla XUL/CDEnext/Windows dialogs... that's not hard... :)
> I am willing to cooperate here and help marco with some specs etc. to make the
> Gnome print dialog more flexible (e.g. that it can support more than one print
> system - the CDEnext and KDE print dialogs are already able to do that since
> years...).

It sounds reasonable to work on a more complete design of the dialog. (I may try
to get a proper usability review on it while I'm at it too). libgnomeprintui
dialog seem to be bound to libgnomeprint (it requires a GnomePrintJob). So, in
my limited knowledge, it's not possible to make it support multiple backends.
Though there is apparently some interest in having a dialog in gtk itself
(generic user interface only).

http://mail.gnome.org/archives/gtk-devel-list/2004-April/msg00116.html

Maybe that's the way to go. Anyway I'll try to work on a design and figure out
if we can make it independent from the backend.

> Well, there is actually no need to make an extra Cairo _backend_ (we may better
> put it somewhere in the _middle_ :) ... the Xprint server side supports the
> OpenGL API and allowes to plug-in PostScript code fragments, too - so either
> native Cairo-->OpenGL-->Xprint will work or those parts of a document (like SVG
> plugins) which need it can generate PostScript code fragments (assuming the
> destination PDL allows PS embedding, otherwise the OpenGL path should be used
> (which is better anyway since it can support transparency)).

Xprint is interesting to me only if we can adopt it as a common print system for
GNOME/Mozilla. I noticed it's now hosted at freedesktop.org, there has been
already discussions about adopting it in GNOME? What's the situation with KDE,
is it one of the supported backends, the only one?
Sorry, I need to be educated, print isnt quite my field;)

[mon (javiermon-deactivatedaccount)]

The title says it all. Also, I think every app (at least in main) should use the
standard gnome dialogs (including the printing one).

[Leon-sha (leon-sha)]

Printing support was added in GTK+ 2.10.
The API Reference Manual is here.
http://developer.gnome.org/doc/API/2.0/gtk/gtk-High-level-Printing-API.html
Seems it has a relationship with cairo.
Can we start to implemente this on cairo based mozilla?

[Leon-sha (leon-sha)]

I have just tried the Gtk Print API in gtk+2.10.
It is quite simple and cool. An example can be found here.
http://cvs.gnome.org/viewcvs/gtk%2B/tests/print-editor.c?view=markup
There are two ways to impletement this in mozilla.
1. Just use the GTK Print API dialog part.
http://developer.gnome.org/doc/API/2.0/gtk/GtkPrintUnixDialog.html
It's maybe simple to do. But I don't think it is a right way.
2. Use the GTK Print high level API
http://developer.gnome.org/doc/API/2.0/gtk/gtk-High-level-Printing-API.html
It may be need a big change in mozilla.

[Ghee-teo (ghee-teo)]

Now that GNOME printing support have progressed moving from lingnomeprint[ui] to
GTK+, is it time know to reconsider this RFE?

The new GTK+ printing API as listed by Leon Sha now provides a set of printing
commands with pango/cairo rendering supports should address the following problems:

- GTK+, a common toolkit layer for Mozilla/Firefox/ThurderBird
- A Print Dialog that is fairly complete and provided hook for customization
- A CUPS backend already in place, and folks at Sun is working on a PAPI (Printing API of OpenStandard, http://www.freestandards.org/en/OpenPrinting)
backend

Benefits of RFE:
- consistent user experiences on printing dialog across gtk+ based apps [1]
- proper interaction with CUPS/PAPI systems [2]
- Better interaction with CUPS/PAPI backends allow better interaction with addition of new printer or browsing of printers.

Pros:
- site policies restrictions still need to be addressed.

So what do you think?

[1] Okay. This may take a while for many of the gtk+ apps to adopt the new dialog and API, but that is the goal :)
[2] This is pretty extensible, so it can be more backend in the future.

[Dar (darren-kenny)]

I would like to add my voice to this too.

While I undestand the original evaluation, as Ghee mentioned, there has been a re-architecture of the printing situation in GTK+ - enough to warrant a re-evaluation at least.

Is there anyone from the Mozilla side that could look into this?

Thanks,

Darren.

[Martin Meyer (elreydetodo)]

There was a HOWTO sent recently to Gnome's desktop-devel list for migrating to the GTK+ print dialog. It gives some pretty good instructions for migrating to the new dialog, and I'm sure the Gnome people would be willing to help get this done if anyone asked. The message/HOWTO can be found at:

http://mail.gnome.org/archives/desktop-devel-list/2006-December/msg00069.html

[Sebastian Urban (surban)]

For many people this is a critical problem! This is one of the reasons, why many people switch back to Windows! Printing on Linux is still terrible. It's a shame that the default installed browser is not able to integrate into the desktop environment! We have to do something about that.

Same for OpenOffice, but the print dialog in OpenOffice is much better than Firefox's.

Is somebody working on it? Pherhaps I will see, what I can do...

[Sebastian Urban (surban)]

Link to Mozilla Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=193001

[John Vivirito (gnomefreak)]

This is not a critical issue, but we will get to it asap.

[Kherron+mozilla (kherron+mozilla)]

Created an attachment (id=289155)
Work in progress - GTK+ print dialog

Work in progress. This displays the GTK+ print dialog instead of the built-in XUL dialog for print requests. It's pretty rough; for example, after dismissing the dialog it crashes while trying to read back the paper size (and there's no place to select a paper size within the dialog).

[Roc-ocallahan (roc-ocallahan)]

Yeah, I think mIsInitedFromPrinter is mainly used by our XUL print dialogs. But I think for safety we should only clear mIsInitedFromPrinter and mIsInitedFromPrefs if the printer name is actually changing. So you'll want to call gtk_print_settings_set_printer and check.

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=297481)
Patch 6 more nits fixed

Put back modifications of those variables when needed.

[Ventnor-bugzilla (ventnor-bugzilla)]

(From update of attachment 297481)
Requesting a1.9; We need to do all we can to improve the printing experience (printing web pages is a surprisingly common task!) and that includes killing off the asinine XUL print dialog on GTK.

[Ventnor-bugzilla (ventnor-bugzilla)]

(In reply to comment #72)
> (From update of attachment 297481 [details])
> Requesting a1.9; We need to do all we can to improve the printing experience
> (printing web pages is a surprisingly common task!) and that includes killing
> off the asinine XUL print dialog on GTK.
>

At Roc's request I must seriously stress the horrific nature of our current setup. Things are so bad that changing advanced options requires typing in a custom _lpr command_ in a special text field. Unlike GNOME's dialog, almost nothing is presented pictorially so a lot of the time you have no idea of the effects of the values you are changing, and this switch gives us easy access to features that even Mozilla's system doesn't support yet GTK gives us for free due to the trivial rewrite of nsDeviceContextSpecG.cpp (which is a very small file).

CUPS will no longer have a monopoly on our GTK printing system which makes support of our GTK builds much easier to do on non-UNIX systems.

We bought a sexy new printer for the office so this has received a large amount of testing by me already, and I did design this patch to smoothly integrate things as much as possible.

[Mtschrep (mtschrep)]

(From update of attachment 297481)
Michael this is awesome. You ready to catch any follow-ups/regressions?

[Ventnor-bugzilla (ventnor-bugzilla)]

(In reply to comment #74)
> (From update of attachment 297481 [details])
> Michael this is awesome. You ready to catch any follow-ups/regressions?
>

I can only do my best! :-)

[Reed Loden (reed)]

Checking in configure.in;
/cvsroot/mozilla/configure.in,v <-- configure.in
new revision: 1.1912; previous revision: 1.1911
done
Checking in config/system-headers;
/cvsroot/mozilla/config/system-headers,v <-- system-headers
new revision: 3.33; previous revision: 3.32
done
Checking in embedding/components/printingui/src/unixshared/nsPrintingPromptService.cpp;
/cvsroot/mozilla/embedding/components/printingui/src/unixshared/nsPrintingPromptService.cpp,v <-- nsPrintingPromptService.cpp
new revision: 1.19; previous revision: 1.18
done
RCS file: /cvsroot/mozilla/toolkit/locales/en-US/chrome/global/gnomeprintdialog.properties,v
done
Checking in toolkit/locales/en-US/chrome/global/gnomeprintdialog.properties;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/global/gnomeprintdialog.properties,v <-- gnomeprintdialog.properties
initial revision: 1.1
done
Checking in toolkit/locales/jar.mn;
/cvsroot/mozilla/toolkit/locales/jar.mn,v <-- jar.mn
new revision: 1.45; previous revision: 1.44
done
Checking in layout/printing/nsPrintEngine.cpp;
/cvsroot/mozilla/layout/printing/nsPrintEngine.cpp,v <-- nsPrintEngine.cpp
new revision: 1.159; previous revision: 1.158
done
Checking in widget/public/Makefile.in;
/cvsroot/mozilla/widget/public/Makefile.in,v <-- Makefile.in
new revision: 1.116; previous revision: 1.115
done
RCS file: /cvsroot/mozilla/widget/public/nsIPrintDialogService.h,v
done
Checking in widget/public/nsIPrintDialogService.h;
/cvsroot/mozilla/widget/public/nsIPrintDialogService.h,v <-- nsIPrintDialogService.h
initial revision: 3.1
done
RCS file: /cvsroot/mozilla/widget/public/nsIPrintSettingsGTK.idl,v
done
Checking in widget/public/nsIPrintSettingsGTK.idl;
/cvsroot/mozilla/widget/public/nsIPrintSettingsGTK.idl,v <-- nsIPrintSettingsGTK.idl
initial revision: 3.1
done
Checking in widget/public/nsWidgetsCID.h;
/cvsroot/mozilla/widget/public/nsWidgetsCID.h,v <-- nsWidgetsCID.h
new revision: 3.51; previous revision: 3.50
done
Checking in widget/src/gtk2/Makefile.in;
/cvsroot/mozilla/widget/src/gtk2/Makefile.in,v <-- Makefile.in
new revision: 1.71; previous revision: 1.70
done
Checking in widget/src/gtk2/nsDeviceContextSpecG.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsDeviceContextSpecG.cpp,v <-- nsDeviceContextSpecG.cpp
new revision: 1.96; previous revision: 1.95
done
Checking in widget/src/gtk2/nsDeviceContextSpecG.h;
/cvsroot/mozilla/widget/src/gtk2/nsDeviceContextSpecG.h,v <-- nsDeviceContextSpecG.h
new revision: 1.42; previous revision: 1.41
done
RCS file: /cvsroot/mozilla/widget/src/gtk2/nsPrintDialogGTK.cpp,v
done
Checking in widget/src/gtk2/nsPrintDialogGTK.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsPrintDialogGTK.cpp,v <-- nsPrintDialogGTK.cpp
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/widget/src/gtk2/nsPrintDialogGTK.h,v
done
Checking in widget/src/gtk2/nsPrintDialogGTK.h;
/cvsroot/mozilla/widget/src/gtk2/nsPrintDialogGTK.h,v <-- nsPrintDialogGTK.h
initial revision: 1.1
done
Removing widget/src/gtk2/nsPrintJobFactoryGTK.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsPrintJobFactoryGTK.cpp,v <-- nsPrintJobFactoryGTK.cpp
new revision: delete; previous revision: 1.1
done
Removing widget/src/gtk2/nsPrintJobFactoryGTK.h;
/cvsro...

[Ginn-chen (ginn-chen)]

"nsDeviceContextSpecG.cpp", line 678: Error: nsISupports::AddRef() is not accessible from nsDeviceContextSpecGTK::EndDocument().

Should it be NS_ADDREF(mSpoolFile.get()) ?

[Reed Loden (reed)]

(In reply to comment #77)
> "nsDeviceContextSpecG.cpp", line 678: Error: nsISupports::AddRef() is not
> accessible from nsDeviceContextSpecGTK::EndDocument().
>
> Should it be NS_ADDREF(mSpoolFile.get()) ?

Checking in widget/src/gtk2/nsDeviceContextSpecG.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsDeviceContextSpecG.cpp,v <-- nsDeviceContextSpecG.cpp
new revision: 1.97; previous revision: 1.96
done

[Ginn-chen (ginn-chen)]

It works.

[Reed Loden (reed)]

This causes the printing test from bug 396024 to crash during mochitest.

Part of the stack:
(gdb) bt full
#0 0xffffe410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb73e8e96 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2 0xb73e8ca7 in sleep () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#3 0xb7f0ee03 in ah_crap_handler (signum=11) at nsSigHandlers.cpp:149
No locals.
#4 0xb7f23251 in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:216
        oldact = (sigaction *) 0xb749bff4
#5 <signal handler called>
No symbol table info available.
#6 0xb5b95589 in DocumentViewerImpl::PrintPreview (this=0x8ccb900,
    aPrintSettings=0x8ccc488, aChildDOMWin=0x0, aWebProgressListener=0x8c824d0)
    at /home/reed/mozilla/builds/mozilla/layout/base/nsDocumentViewer.cpp:3537
        rv = <value optimized out>
        xulDoc = {mRawPtr = 0x0}
        docShell = {mRawPtr = 0x0}
        presShell = {mRawPtr = 0x0}
#7 0xb7e0265d in NS_InvokeByIndex_P ()
    at /home/reed/mozilla/builds/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfo.cpp:73
        nsIInterfaceInfo::COMTypeInfo<int>::kIID = {m0 = 559791620, m1 = 38055,
  m2 = 4562, m3 = "�X\000\200_\212]�"}
        nsISupports::COMTypeInfo<int>::kIID = {m0 = 0, m1 = 0, m2 = 0,
  m3 = "�\000\000\000\000\000\000F"}

[Reed Loden (reed)]

Glancing at the numbers, this actually might be a Ts win, too! :)

[Martijn-martijn (martijn-martijn)]

The mochitest for bug 396024 is testing print preview code, but doesn't really work right now, because no printers are installed on the tinderboxes.
So it might be good to test if the patch doesn't cause a crash when no printers are installed.
Maybe bug 408355 is related?

Otherwise, I don't know why it's causing the crash. I guess you might want to disable the mochitest then, although I would prefer it if the crash was fixed.

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=297600)
Fix test failure

This special-cases print preview in GetSurfaceForPrinter so we don't try to detect the format capabilities of a non-existent printer when no printer is installed.

I think this is the problem, I can't really tell. But if no printers are on Tinderbox this seems likely.

[Ventnor-bugzilla (ventnor-bugzilla)]

(From update of attachment 297600)
This doesn't fix it.

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=297920)
Fix test failure

It took a while but I finally figured out the test failure. Yay! It turns out it was an ugly race condition in the event loop which caused one of the frames to be destroyed before we got the chance to show the print preview. This is fixed by moving the printer enumeration (which causes the probing of the event loop) to a much later location.

Some code had to be changed to make sure this move didn't cause more crashes. I also added a failure return where the crash happened. We return early when we detect the absence of other important global variables, so why not the mContainer? This will make print and print preview much safer.

[Roc-ocallahan (roc-ocallahan)]

This is definitely an improvement, but we're potentially just moving the crash to code that creates the devicecontextspec, namely nsPrintEngine::DoCommonPrint. We need to look at the "silent printing" APIs and figure out which one we should make potentially spin the event loop.

Or else we could do something a little more outrageous and maintain the default printer in nsToolkitGTK, by re-getting the default printer periodically and asynchronously.

[Kherron+mozilla (kherron+mozilla)]

(In reply to comment #86)
> Or else we could do something a little more outrageous and maintain the default
> printer in nsToolkitGTK, by re-getting the default printer periodically and
> asynchronously.

As I understand it, neither the GTK nor CUPS layer caches printers, so each printer enumeration can result in queries to remote print servers. See eg <http://bugzilla.gnome.org/show_bug.cgi?id=370069> and <http://bugzilla.gnome.org/show_bug.cgi?id=508905>.

[Ventnor-bugzilla (ventnor-bugzilla)]

(In reply to comment #86)
> This is definitely an improvement, but we're potentially just moving the crash
> to code that creates the devicecontextspec, namely
> nsPrintEngine::DoCommonPrint. We need to look at the "silent printing" APIs and
> figure out which one we should make potentially spin the event loop.

The problem is there is no "silent printing API's", it all takes the same path. Its just that silent printing skips the code that shows the print dialog. The reason I put it there is to do it as least as possible. We don't need it for print preview and the print dialog will give us a GtkPrinter anyway. I think this is the safest place to put it, and with the extra failure checks in nsDocumentViewer it will become even safer.

> Or else we could do something a little more outrageous and maintain the default
> printer in nsToolkitGTK, by re-getting the default printer periodically and
> asynchronously.

We should never do anything that can encourage races, in this case between nsToolkitGTK and nsDeviceContextSpecGTK.

[Roc-ocallahan (roc-ocallahan)]

(In reply to comment #88)
> I think
> this is the safest place to put it, and with the extra failure checks in
> nsDocumentViewer it will become even safer.

Those checks may block that particular crash, but processing events during nsDeviceContextSpecGTK::Init is still BAD BAD BAD scary stuff.

> > Or else we could do something a little more outrageous and maintain the
> > default printer in nsToolkitGTK, by re-getting the default printer
> > periodically and asynchronously.
>
> We should never do anything that can encourage races, in this case between
> nsToolkitGTK and nsDeviceContextSpecGTK.

What races? You're worried about the default printer changing or going away between the poll and the print?

How do things work today? If CUPS already does some kind of expensive checking of remote printers, do we just block completely? do we process events during that time? if we process events, during which print API call? Someone please read the code so I don't have to.

[Roc-ocallahan (roc-ocallahan)]

This seems lame, GTK must have some local knowledge of what the default printer is, but there doesn't seem any way to get that directly.

As a mega-lame solution to "silent printing", could we open the print dialog and then instantly close it as if the user had clicked OK?

[Roc-ocallahan (roc-ocallahan)]

We decided to add a new SetupSilentPrinting method to nsIPrintSettings that will be called by nsPrintEngine::DoCommonPrint at the place where it currently calls ShowPrintDialog for non-silent printing, which spins the event loop. SetupSilentPrinting will be allowed to spin the event loop. This should add no new event-loop hazards, because if the print.always_print_silent preference is created and set to false, this code would always pop up the dialog and spin the event loop even for clients that set silentPrinting to true explicitly.

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=298171)
Attempt to constrain the event loop run

Yeah, this seems to work.

[Roc-ocallahan (roc-ocallahan)]

(From update of attachment 298171)
+ /**
+ * We call this function so that anything that requires a run of the event loop
+ * can do so safely. The print dialog runs the event loop but in silent printing
+ * that doesn't happen.
+ */

Please document that either SetupSilentPrinting or ShowPrintDialog (but not both) must be called by the print engine when actually printing.

+ // XXX Some platforms allow the user to change the ShrinkToFit option so change it here too

How about
"// The user might have changed shrink-to-fit in the print dialog, so update our copy of its state"
(shouldn't be XXX since there is not a known probem with this)

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=298173)
Comment fix

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=298177)
...And rev the UUID

I'm so bad at remembering to do this :(

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=298186)
...And update to tip

[Roc-ocallahan (roc-ocallahan)]

I just realized that nsIPrintSettingsGTK shouldn't be IDL. In fact, it shouldn't even exist. The code should just use nsPrintSettingsGTK directly.

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=298194)
Address Roc's literally last-second interface rewrite comment

When this gets checked in, the files nsPrintJobFactoryGTK.cpp and nsPrintJobGTK.cpp must be removed from widget/src/gtk2/.

[Roc-ocallahan (roc-ocallahan)]

(From update of attachment 298194)
+#define NS_IPRINTSETTINGSGTK_IID \

call it NS_PRINTSETTINGSGTK_CID

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=298195)
Address picky comment

[Reed Loden (reed)]

Created an attachment (id=298199)
Include file removals and remove some other old code

[Reed Loden (reed)]

Checking in configure.in;
/cvsroot/mozilla/configure.in,v <-- configure.in
new revision: 1.1916; previous revision: 1.1915
done
Checking in config/system-headers;
/cvsroot/mozilla/config/system-headers,v <-- system-headers
new revision: 3.35; previous revision: 3.34
done
Checking in embedding/components/printingui/src/unixshared/nsPrintingPromptService.cpp;
/cvsroot/mozilla/embedding/components/printingui/src/unixshared/nsPrintingPromptService.cpp,v <-- nsPrintingPromptService.cpp
new revision: 1.21; previous revision: 1.20
done
Checking in toolkit/locales/en-US/chrome/global/gnomeprintdialog.properties;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/global/gnomeprintdialog.properties,v <-- gnomeprintdialog.properties
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/locales/jar.mn;
/cvsroot/mozilla/toolkit/locales/jar.mn,v <-- jar.mn
new revision: 1.47; previous revision: 1.46
done
Checking in layout/printing/nsPrintEngine.cpp;
/cvsroot/mozilla/layout/printing/nsPrintEngine.cpp,v <-- nsPrintEngine.cpp
new revision: 1.161; previous revision: 1.160
done
Checking in layout/base/nsDocumentViewer.cpp;
/cvsroot/mozilla/layout/base/nsDocumentViewer.cpp,v <-- nsDocumentViewer.cpp
new revision: 1.561; previous revision: 1.560
done
Checking in widget/src/xpwidgets/nsPrintSettingsImpl.cpp;
/cvsroot/mozilla/widget/src/xpwidgets/nsPrintSettingsImpl.cpp,v <-- nsPrintSettingsImpl.cpp
new revision: 1.42; previous revision: 1.41
done
Checking in widget/public/Makefile.in;
/cvsroot/mozilla/widget/public/Makefile.in,v <-- Makefile.in
new revision: 1.119; previous revision: 1.118
done
Checking in widget/public/nsIPrintDialogService.h;
/cvsroot/mozilla/widget/public/nsIPrintDialogService.h,v <-- nsIPrintDialogService.h
new revision: 3.3; previous revision: 3.2
done
Checking in widget/public/nsIPrintSettings.idl;
/cvsroot/mozilla/widget/public/nsIPrintSettings.idl,v <-- nsIPrintSettings.idl
new revision: 1.44; previous revision: 1.43
done
Checking in widget/public/nsWidgetsCID.h;
/cvsroot/mozilla/widget/public/nsWidgetsCID.h,v <-- nsWidgetsCID.h
new revision: 3.53; previous revision: 3.52
done
Checking in widget/src/gtk2/Makefile.in;
/cvsroot/mozilla/widget/src/gtk2/Makefile.in,v <-- Makefile.in
new revision: 1.73; previous revision: 1.72
done
Checking in widget/src/gtk2/nsDeviceContextSpecG.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsDeviceContextSpecG.cpp,v <-- nsDeviceContextSpecG.cpp
new revision: 1.99; previous revision: 1.98
done
Checking in widget/src/gtk2/nsDeviceContextSpecG.h;
/cvsroot/mozilla/widget/src/gtk2/nsDeviceContextSpecG.h,v <-- nsDeviceContextSpecG.h
new revision: 1.44; previous revision: 1.43
done
Removing widget/src/gtk2/nsIPrintJobGTK.h;
/cvsroot/mozilla/widget/src/gtk2/nsIPrintJobGTK.h,v <-- nsIPrintJobGTK.h
new revision: delete; previous revision: 1.2
done
Checking in widget/src/gtk2/nsPrintDialogGTK.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsPrintDialogGTK.cpp,v <-- nsPrintDialogGTK.cpp
new revision: 1.3; previous revision: 1.2
done
Checking in widget/src/gtk2/nsPrintDialogGTK.h;
/cvsroot/mozilla/widget/src/gtk2/nsPrintDialogGTK.h,v <-- nsPrintDialogGTK.h
new revision: 1.3; previous revision: ...

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=298352)
Possible Crash follow-up

This may be the cause of some people's crashes lately, see if this fixes anything.

[Reed Loden (reed)]

Checking in widget/src/gtk2/nsPrintSettingsGTK.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsPrintSettingsGTK.cpp,v <-- nsPrintSettingsGTK.cpp
new revision: 1.4; previous revision: 1.3
done

[Fredrik Larsson (nossralf)]

For reference, the "crashes on File > Page Setup" bug is bug 413414. (I hope this doesn't qualify as bug spam.)

[Ventnor-bugzilla (ventnor-bugzilla)]

Created an attachment (id=298404)
Followup 2: HIG fixes

This will make the custom text dialog obey the HIG more by switching the order of the buttons, and marking one as the default for when you press Enter.

[Reed Loden (reed)]

Checking in widget/src/gtk2/nsPrintDialogGTK.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsPrintDialogGTK.cpp,v <-- nsPrintDialogGTK.cpp
new revision: 1.4; previous revision: 1.3
done

[Ispence (ispence)]

This is just a nitpick, but it'd be nice if the page setup and other dialogs had a firefox icon (well, the icon of the program using the toolkit)

[Sebastian Urban (surban)]

Firefox 3 is included in Hardy.