Can you explain this bug a little better?

The solution for this bug will be to introduce a "pluggable" dialog service. Just like the network libs use the nsIPrompt mechanism for flynig dialogs and embedders can override them with their own dialogs. My guess is that much like what we do for netwerk, we will pass in a nsIInterfaceRequestor for callbacks and then do a GetInterface on the callbacks for the nsIPrintingPrompt interface. The implementation of that can then be elsewhere like in the embedding directory. The a particular platform can choose to use the nsIInterfaceRequestor or just fly their own native one. On Windows we may move entirely away from the XPDialog, but certainly for Linux we need to do this.

I assume this solution would remove entirely the dependencies in gfx on dom and windowwatcher? Would gfx become dependent on embedcomponents, or would print dialogs be invoked entirely from outside of gfx?

Marking nsbeta1+.

nsbeta1- per adt triage

topembed+ per adt triage

rods: How does this affect bug 136058 ("Implement nsPrinterFeatures" - the idea of this RFE is to create a service to query printer properties/attributes like available paper sizes/orientations for a specified printer...) ? AFAIK embedders would need this info to "fly their" print dialog without using hardcoded values in their print dialog (currently both PostScript module and Xprint module use the printerfeatures prototype in nsDeviceContextSpecGTK/nsDeviceContextSpecXlib - we only need to make the code a XPCOM service... :)

Phase #1 patch is in Bug 135441 I will attach an overview document soon.

this is more up-to-date

rods: Since you are already touching all platforms - is it possible to implement the API calls for bug 133258 ("Enhance nsIDeviceContext print API with an additional level to support multiple documents in one print job") with this patch - or (at least) rename s/BeginDocument/BeginJob/ and s/EndDocument/EndJob/, please ?

Read about Phase #2

Glad to see that nsIPrintPromptService has landed, but, needless to say, a pluggable print dialog system is useless if mozilla doesn't invoke print dialogs through it. I hope rod's patch can land asap; we're (galeon) still getting tortured by javascript.print()...

Heh, spoke too soon eh? Roadmap looks good.

Comment on attachment 82090 [details] [diff] [review] patch r=dcone

Comment on attachment 82090 [details] [diff] [review] patch sr=attinasi, based partially on email comments that testing has been thorough and on all platforms

fixed

verifying, this has been working for a couple of weeks

Let's get this verified by QA either on the trunk or if they are substantial, please create a test build with the batch and the branch and let QA test that.

verified...

this patch has a bunch of conflicts.

Here the patch of what was checked in and this is a list of things that had changed: 1) Change to encode '\n' as '_' in printer names for prefs (apparently I was testing this idea; took out the calling code but left this in, the code worked fin ein testing) 2) The nsDeviceContextSpecOS2.cpp which had conflicts was changed to the one mkapply sent me. 3) At the last minute we discovered that the attr isPrintPreview in the nsIWebBrowserPrint was no longer being used, so I removed the two calls to it in DocViewer, It was removed later from the IDL. 4) Several Mac makefile file changes that came out of the last round of builds Conrad did 5) For reason I can't explain I must changed to debug output statments from inside a "if (doDebug)" if statment in printjoboptions.js 6) A bunch of stuff removed from embedding/browser/powerplant/source/CPrintAttachment.cpp and few lines added to better use the new APIs (I reviewed) 7) A change in an embedding make to use a renamed directory from gtk to unixshared. 8) A bunch of changes to get the viewer app working with printing again. So here is my justification for checking this all in without further reviews: Conrad had just spent a lot of time diligently doing builds on Mac for Mac9, Carbon, and OSX. Waiting any length of time might for re-reviews for I think are fairly minor issues might require doing builds on the Mac again. Item #1 - that is the only item of concern, but it works fine. Item #3 - I didn't feel removing code was worth a re-review. Item #6 - I reviewed. Item #8 - nobody but the layout-group cares about viewer and I am usually the only one you uses the Print" menu item, so I figure that didn't really need to be reviewed at this point, I didn't even have a bug on this, so obivously nobody uses it. Most of the others were makefile changes that cam out of Conrad's builds.

This is the the patch against the branch, al the new embedding files are already in on the branch, but not in the build.

Attachment 84098 [details] [diff] is in Bug 135441 This attachment is the correct one

adding adt1.0.0+. Please get drivers approval and then check into the 1.0 branch.

changing to adt1.0.1+ for checkin to the 1.0 branch. Please get drivers approval before checking in.

please land on the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword, and add the "fixed1.0.1" keyword.

checked in on branch