70950 - Need to able to print from javascript

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Kevin McCluskey (gone)]

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.

Comment 1

[Marek Z. Jeziorek]

per triage: TM to Future

Comment 2

[dcone (gone)]

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

Comment 3

[rvj]

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?

Comment 4

[rvj]

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

Comment 5

[dcone (gone)]

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

Comment 6

[dcone (gone)]

Attachment: a patch to the PrintOptions IDL which adds the silent parameter

Comment 7

[Kevin McCluskey (gone)]

r=[e-mail]

Comment 8

[Marc Attinasi]

sr=attinasi

Comment 9

[Peter Trudelle]

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

Comment 10

[dcone (gone)]

fixed

Comment 11

[Marek Z. Jeziorek]

I was wrong Future'ing it. 

Comment 12

[sujay]

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!

Comment 13

[sujay]

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

Comment 14

[rvj]

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); }

}

Comment 15

[rvj]

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

Comment 16

[rvj]

... 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();

}

Comment 17

[Peter Trudelle]

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.

Comment 18

[rods (gone)]

taking bug

Comment 19

[Stephane M. Cote]

Adding myself to the CC list... working one OEone printing system

This will simplify my task enormously!!!!

Comment 20

[rods (gone)]

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.

Comment 21

[sujay]

verified.

Comment 22

[Torsten Scheck]

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!