Closed Bug 61580 Opened 24 years ago Closed 24 years ago

[RFE] javascript quiet printing support

Categories

(Core :: DOM: Navigation, enhancement, P3)

enhancement

Tracking

()

VERIFIED DUPLICATE of bug 70950

People

(Reporter: rvj, Assigned: dcone)

Details

Attachments

(1 file)

Having read many of the printing bug reports (preview, prefs, setup) etc, I still have little idea as to when any functionality will be available via javascript. In particular it would be greatly appreciated if javascript access to quiet mode printing was implimented as an interim solution. i.e. print a single copy of the contents of an iframe to the default printer Can anyone confirm that the bug 17141 covers the javascript side of things?
Marking NEW and adding RFE
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: other → All
Hardware: Other → All
Summary: javascript access to printing functionality (& quiet printing) → [RFE] javascript access to printing functionality (& quiet printing)
This is a Javascript engine issue
Assignee: dcone → rogerl
Component: Printing → Javascript Engine
QA Contact: shrir → pschwartau
This is not JS Engine. In JS Engine, we do not have DOM objects, but the lower-level things like Date() and Number(). If this doesn't belong in the Printing component, I don't know which component it belongs in. To Browser-General for advice and further triage -
Assignee: rogerl → asa
Component: Javascript Engine → Browser-General
QA Contact: pschwartau → doronr
FYI I had assumed that this was an XPCOM interface issue. i.e. the abilty to perform the equivalent of MS IE's print button (no dialog box). As bug 17141 (quiet printing) suggests this does not seem to have been linked up. An example of a javascript call would be appreciated when resolved. I presume access to other print/preview functionality via javascript ( setting printing prefs, preview, etc) is also an XPCOM interface issue?
over to printing.
Assignee: asa → dcone
Component: Browser-General → Printing
QA Contact: doronr → shrir
This not a printing issue. Sending to DOM for there shot at this. There is a "QUIET" parameter on the API currently. On some platforms the dialog may still come up..there is a bug on that.
Assignee: dcone → jst
Component: Printing → DOM Level 2
QA Contact: shrir → ian
I must say that I'm a bit afraid to make functionality like this available to javascript. Imagine you're playing with your new ultra cool printer that prints photo quality pictures if you insert a $50 paper in the printer and you happen to have everything set up and you're about to print something just as someone sends sends you some spam mail and you read that spam mail that contains the javascript command that prints this spam mail on my one and only $50 sheet of paper that you need for the presentation you're giving the following morning! I must say I would *not* like web browser application to be able to print random web pages w/o me always being prompted before the page is actually printed so that I can stop it if I don't want the page printed. I bet the porn sites out there would love this feature :-) This is something that could be added but it should only be available to signed scripts. Pushing this to Future for now.
Target Milestone: --- → Future
jst: Very much agreed.
Is it not possible to give XUL developers an interim solution so that they can develop applications that at least require a user physically click on the interface - just like IE's print button ? Presumably IE and MS have the same concerns?
Would it be better if I filed a new RFE asking for a XUL widget for printing? The user would then have to physically select the XUL widget to invoke the printing functionality - so avoiding doing this using general purpose javscript. This is ALSO how it is done in other development languages such as VB which embed a 'printer control'. It seems a better way to encapsulate printing functionality in general and address your security/absure concerns. Assuming that such a printing widget had an attribute QUIET=TRUE then would be fine. The QUIET attribute could also be made non-scriptable if that is a concern. <PRINT copies=1 quiet=true orientation=landscape papersize=A4 style="width:20px;height:10px" value="Print" src="iframetag" />
I'm sure it's possible to print with (and w/o?) a dialog from XUL js, I bet that's how the print button/menu in the mozilla UI is implemented, is that what you need or is there still something missing?
For me, Mozilla always display the print dialog box (under Windows) when the print button is clicked. I cant find any documentation (or Mozilla a button) that produces the W/O effect. As far as I know display is the normal operation for the JS print() function. Maybe my documentation is out of date, but I can find how to supress it in JS or is it a pref? In IE the dialog box is always suppressed when the print button is clicked. (Quiet Mode) This is currently all I am trying to do. Use the printer default settings However in the longer term there ALSO has to be a method of identifying a particular iframe to print, i.e. particularly if documents are created via DOM methods in a hidden iframe. as well as the ability to set/reset the printer defaults through javascript.
Ok, this is a UI issue only and from reading this comment in navigator.js this is more an embedding bug than it is a DOM bug: function BrowserPrint() { // using _content.print() until printing becomes scriptable on docShell _content.print(); } Over to embedding.
Assignee: jst → adamlock
Component: DOM Level 2 → Embedding: Docshell
QA Contact: ian → adamlock
Target Milestone: Future → ---
I have attached a skelton XUL file with code which I understand does impliment quiet printing if "manually" exported . However I do not understand what is required to achieve this. Can anyone clarify if I can "export manually" using javascript????
a) any approx timeframe or milestone for this? b) is the following code the likely form of the javascript call for printing? c) will the same interface allow javascript to read the default printer settings? function quietprint() var iframe=document.getElementById("iframe"); var contentViewerFile = iframe.docShell.contentViewer.QueryInterface (Components.interfaces.nsIContentViewerFile); contentViewerFile.Print(true, null, null); }
I don't believe this is an embedding bug. The issue here is whether you can print from javascript or not and you can. The secondary issue is whether you can print silently from content. My gut feeling is that silent printing will never happen for the reasons mentioned previously. It would be handy to print silently from chrome however.
Thanks. I had a sneeking suspicion you would say it was not an embedding issue (given several previous attempts to locate a suitable owner) 1. As regards quiet printing I am not sure why 'within the context of a trusted XUL environment' quiet printing scripts should not be supported. IE supports this feature happily enough and in any case I'm sure it could be supported in XUL in the form of a XUL PRINT element (as suggested earlier) which would alay fears of 'rogue' scripts 2. Are you saying that it is currently possible to using javascript to access the printer API to read the system default printer settings such as orientation, number of copies, default printer title, etc. ? Ive not seen any example of how this can be done. I cant find any documentation indicating how this achieved other than skeleton code outlined in an earlier post. ------------------------------------------------------------------------ It seems that the main problem is in identifying the correct owner for printing related development. Please could you adise who is or route this request to the appropriate owner or component topic. Many thanks in advance.
Renaming bug and reassigning to Don. The bug now deals with the issue of allowing CHROME to print silently. It is recognized that untrusted content should never get this ability for security reasons.
Assignee: adamlock → dcone
Summary: [RFE] javascript access to printing functionality (& quiet printing) → [RFE] javascript quiet printing support
we have a requirement for printing silently.. which I will dup this one against. *** This bug has been marked as a duplicate of 70950 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified dup.
Status: RESOLVED → VERIFIED
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: