An embedded app needs to be able to optionally prevent the print dialog from comming up. This is so the embedded app can choose to "fly" its own dialog.

per triage: TM to Future

*** Bug 61580 has been marked as a duplicate of this bug. ***

I hope that the scope of bug 61580 does not get lost in the latest bug report. Recently the original summary line was changed. Originally bug 61580 was requesting javascript access to all printing functionality from within a XUL environment. Given the time that this particular bug has been bounced between potential owners can I restate the issue(s). Javascript access to all printing functionality from XUL a) silent printing from javascript within XUL as an interim solution b) access to printer setup reading/setting default via javscript with XUL c) access to preview functionality from javascript within XUL In fact the original silent printing bug was bug 17141. Just out of interest, is there any reason why chronological bug history is not preserved?

PPS Do I take it the latest bug report reference to an embedded apps refers to XUL or to the Mozilla ActiveX control?

*** Bug 73132 has been marked as a duplicate of this bug. ***

sr=attinasi

cc danm, marek. We thought this bug was required for overriding print dialog in embedding. Marek, why did you future it?

fixed

I was wrong Future'ing it.

Don/Kevin, can either of you verify this one in embed, thats out of my area... you can mark this bug VERIFIED-FIXED after doing so...thanks!

Kevin/Don, can one of you verify this and mark this bug verified-fixed? embedding is out of my reach...thanks..

please can anyone confirm that this bug fix does allow javascript to silently print iframe content in a XUL application. this bug and its predecessors, seems to get merged with other bugs relating to embedding (see 61580 and 17141 for full case histories) If this bug has been fixed, can we please have an example of how to use javscript to print the contents of a specfic iframe. Is the following correct? function quietprint() { var iframe=document.getElementById("iframe"); var contentViewerFile = iframe.docShell.contentViewer.QueryInterface (Components.interfaces.nsIContentViewerFile); contentViewerFile.Print(true, null, null); } }

Apologies for reopening this bug butI am trying to find out if the bug has actually been fixed. PLEASE can anyone confirm whether it now possible to print in 'quiet' mode from a xul application using the javascript(xpcom) as suggested above (or something like it). This bug keeps re-occurring 17141, 61580, 70950, 104501 to name just a few but it is not clear if it actually has been fixed. I assume it has because 106015 seems to imply it has - so please can someone clarify the javascript necessary ? It really would be nice to get some feedback. Thanks

... or am I correct in thinking that the xul javscript method is to call the printoption interface and then then apply the standard print() method to the target iframe? function quietprint() { // xpcom call to print options to set to silent mode ??? // standardprint request document.getElementById("iframe").print(); }

Another reason is to avoid throwing a useless dialog in the user's face. 95% of the time, the dialog is immediately dismissed anyway, so it is just a delay and annoyance. IMO, it should not be shown after clicking the print button on the toolbar. This is the way MS Office apps work, so most users will be comfortable with it.

taking bug

Adding myself to the CC list... working one OEone printing system This will simplify my task enormously!!!!

If you want to directly print an IFrame from JS please open a new bug. This bug is now fixed. You can print from JS without the dialog showing.

verified.

Sorry, I couldn't find a hint how to actually use silent print (without printer dialog) from JavaScript. If there is a way to do it and I just missed it: Is it standard-javascript or Mozilla-dependent? In my opinion there should be user/pref.js-entries for trusted sites and pages without the need for showing the printer dialog. Especially for embedded solutions where the user should be spared from too much interaction, such a solution would be nice. Being able to assign a special printer queue to certain pages this way would be my dream. :-) I couldn't find a clue in the user- and Netscape-javascript-docs. But when I searched the web I found many proprietary solutions for IE with ugly headers like this one: <HTML XMLNS:IE><HEAD><?IMPORT NAMESPACE="IE" IMPLEMENTATION="#default"> ... [http://www.webreference.com/js/column93/7.html] Where can I find _standard_ solutions for such obviously widespread problems? If there are no standards, who may I ask to define these standards? I don't want Microsoft to keep the browser monopoly for ever!