Closed
Bug 61580
Opened 24 years ago
Closed 24 years ago
[RFE] javascript quiet printing support
Categories
(Core :: DOM: Navigation, enhancement, P3)
Core
DOM: Navigation
Tracking
()
People
(Reporter: rvj, Assigned: dcone)
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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?
Comment 1•24 years ago
|
||
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)
Assignee | ||
Comment 2•24 years ago
|
||
This is a Javascript engine issue
Assignee: dcone → rogerl
Component: Printing → Javascript Engine
QA Contact: shrir → pschwartau
Comment 3•24 years ago
|
||
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?
Comment 5•24 years ago
|
||
over to printing.
Assignee: asa → dcone
Component: Browser-General → Printing
QA Contact: doronr → shrir
Assignee | ||
Comment 6•24 years ago
|
||
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
Comment 7•24 years ago
|
||
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
Comment 8•24 years ago
|
||
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?
Reporter | ||
Comment 10•24 years ago
|
||
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" />
Comment 11•24 years ago
|
||
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?
Reporter | ||
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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 → ---
Reporter | ||
Comment 14•24 years ago
|
||
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????
Reporter | ||
Comment 15•24 years ago
|
||
Reporter | ||
Comment 16•24 years ago
|
||
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); }
Comment 17•24 years ago
|
||
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.
Reporter | ||
Comment 18•24 years ago
|
||
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.
Comment 19•24 years ago
|
||
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
Assignee | ||
Comment 20•24 years ago
|
||
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
Comment 22•22 years ago
|
||
[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.
Description
•