Can you get some comments about this proposal?
Silent Printing is being able to click print on a button in a web application and having it just print, no dialog. This makes web based point of sale systems just work (after installing the addon) without having to click print twice, once in the application, and once in the print dialog. Most of the requested functionally does seem to be for such things. Here's the original addon http://jsprintsetup.mozdev.org/
(In reply to Shane Caraveo (:mixedpuppy) from comment #2) > > Have you seen the changes in bug 1269300? I'd like to understand what this > provides beyond that. I'd also like to see how any additions might be > integrated into those existing APIs. Yes I have seen last changes in bug 1269300. Functionality is limited to `print` (with current settings and display print dialog), `saveAsPDF` and `printPreview`. The `print` method can't get any `printSettings` which can be used for current print job only and not saved in preferences for next print as is done in `PrintUtils.printWindow`. About integration to current API I think that is possible, but not for all proposed functionality. For example if `tabs.printprintSettings)` can get optional `printSettings` providing set nsIPrintSetting attributes. There are also another useful methods that I don't know how can be implemented to current API. > What do you mean by silent printing? Silent printing is when print executed bypassing print dialog (select printer/print settings). > > > - print of single frame > > Please describe that functionality better. I will give an example. In tab is displayed page (Web API Window) with frames https://developer.mozilla.org/en-US/docs/Web/API/Window/frames. I want to print particular frame from window.frames with following code. window.frames.jsPrintSetup.print(printSettings) > > > - printing with customized settings to desired printer > > - getting list of available printers > > Something like this would have to be behind user interaction rather than > just letting an addon get this kind of data. Yes. I thing that this is subject of security/privacy and for that must be required user permissions on host basis. > > That's very cool that you've done the experiment. Since we have some print > APIs in place I'd like to be sure we integrate with that. I'd also like a > better explanation of the use cases. Then we would be better able to make a > decision. I have tried to extended explanation of use cases. https://github.com/edabg/web-ext-experiment-printservice#iv-test-case
Hi Dimitar, this has been added to the agenda for the August 22 WebExtensions APIs triage meeting. Would you be able to join us? We can talk about next steps for your experiment. Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage Agenda: https://docs.google.com/document/d/11SdY-aRhvPU3SvH8jpj0covj3Teq9_GJl8wMeEeSVwo/edit#
Thanks for joining us, Dimitar! In the meeting, we discussed two requirements for this to land: 1) users still need to interact with the print dialogue 2) this has to fit under the same namespace as the print API Once those to requirements are confirmed in the experiment, we will assign a mentor to help land this in Firefox.
(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #7) > Thanks for joining us, Dimitar! > > In the meeting, we discussed two requirements for this to land: > > 1) users still need to interact with the print dialogue > 2) this has to fit under the same namespace as the print API > > Once those to requirements are confirmed in the experiment, we will assign a > mentor to help land this in Firefox. doesn't #1 stop one of the main uses cases which is silent printing? That functionality is quite useful when for web based point of sale applications.
Silent printing is printing without repeated interaction. It was previously possible with jsprintsetup-addon or java-applet. The user should need one interaction to enable it (previously: install addon or accept java-security dialog). After that, printing should be possible without interaction, e.g. a website that polls data and occasionally prints something out. It would be very nice if browsers get that functionality back, otherwise users need to run tools besides a browser to get it (e.g.: https://stackoverflow.com/questions/27057816/alternative-to-jzebra-qz-java-raw-print-plugin-after-npapi-being-dropped-on-chro/28783269#28783269).
The main reason to suppress print dialog is that it's override print setting with stored one at last print job. Of course using of this feature and all other about printing MUST BE CONTROLLED from user. I suggest to be added `special permissions to extensions` for using `printservice` and extensions `have to implement host based access control`. I have implemented in experiment security features and explained here https://github.com/edabg/web-ext-experiment-printservice/blob/master/README.md#security
I stumbled on this while trying to find out when JS Print Setup would be updated for the upcoming WebExtension changes. Mozilla with JS Print Setup is the only way we have found to create a seamless cross-platform printing experience similar to a native or Java app. It's not just POS printing either. Our group of companies utilizes both an in-house POS system and reservation system - both web apps. JS Print Setup is used extensively to enable printing without a dialogue and to enforce consistent settings and layout from all clients. Consider a reservation specialist at one of our companies... This person prints frequently from office applications, 3rd party web sites, etc. They change print settings all the time. Duplex on/off, shrink to fit on/off, background color/images on/off, margins and headers/footers changed. This means that the last saved print settings at any given time are all over the map. Now they go to print a payment receipt or contract and end up with a two inch margin and the URL at the top. That doesn't look very professional to hand to a customer. We used to deal with an impossible to maintain user.js for every profile that would reset to our defaults for a number of various printer models. That has the obvious disadvantage of only resetting when the browser is restarted. We also tried enforcing "make sure your printing settings say this every time...". You can imagine how that went. I know some will say "Idiot, send it all to PDF!" Unfortunately, generating dynamic PDFs is slower, more resource intensive, and you still have the problem of users messing with margins, fit to page, etc. With regard to "silent" printing, I'll give another real world example. On any given summer day, one our locations has 2-4 high school kids wrangling a fleet of rental boats and water toys, as well as running a full fuel dock and store. They print a ton of paperwork for the rentals process. How much time is wasted by the poor kid doing four jobs at once who completes a check-in, clicks print, and runs over to the printer to stand there waiting for 30 seconds? Hmm... not printing. Is the printer dead, out of paper, just slow? Nope, forgot to click print *again*. The print.always_print_silent hidden setting can't be toggled at the app level, so not useful when you need it both ways. I read through Dimitar's security features explanation and completely agree. Ask the user for permission to their printer settings once upon first use and enforce host-based access control in the extension. The extension as it is now already implements excellent security. You have to agree to use it the first time and/or explicitly whitelist your/all domains. Discovering this extension was like a light of shining silicon in the sky. Please don't take away the tiny bit of printer interaction and control web application developers are able to leverage. I suspect that most end users are unaware of the mess that is about to happen if this functionality is not preserved. Here's a small sample of vendors recommending or requiring JS Print Setup for their apps: https://wiki.koha-community.org/wiki/Setting_up_slip_printer_to_print_silently http://support.erply.com/installing-firefox-add-ons-and-configuring-receipt-printer/ https://www.manula.com/manuals/inventorylab/inventorylab-user-guide/1/en/topic/zebra-brother http://www.thinkministry.com/kb/check-in-2/workstation-configuration/firefox-printing-preferences/ https://help.eventnut.com/hc/en-us/articles/209635277-Badge-Printing-Guide
Whiteboard: [design-decision-needed] → [design-decision-approved]
The only comment for me is that I completely agree with Jason. We really need this for our Web apps. It will be a very big problem if it stop to work.
We are using JSPrintSetup heavily to print labels (500-1000 a week). Firefox with this Addon is for us the only good way to get the work done (really, printing a label should not be more than a button). I had to fiddle a lot with the FF printing, it seems that the printing function did not evolve much since 1999 (why else would there be a default header and footer with URL and page number?). And the print.print_unwriteable_margin is as well something that could be dumped without been missing (really, a pain in the... have to set that to zero every time manually) I wish, silent printing could be as easy as accessing location or microphone: It asks once for permission which you can save for the domain and done it is. The script handles the rest like page/label size, copies, margins and headers, which printer, etc. Today, we cannot go without JSPrintSetup (I just put all Firefox versions on hold on our Linux machines, our Seedlab would not be able to work on otherwise). Just to print a series of labels (sometimes it is quite a roll at once, when we stage a new transport to Svalbard Global Seed Vault) would be a whole days work otherwise.
ni myself so it gets on my radar.
(In reply to Shane Caraveo (:mixedpuppy) from comment #18) I'm ready. What I have to do next?
(In reply to Dimitar Angelov from comment #19) > (In reply to Shane Caraveo (:mixedpuppy) from comment #18) > > I'm ready. What I have to do next? The first thing that's going to happen is splitting out the silent printing. The other items are likely less contentious. The decision was made that this could not be done without user interaction. It may be possible to rethink how that is handled, but I think getting forward movement is going to require that to be separate. I need to read through everything and get a good look at the experiment before I can comment further.
For all that need the functionality NOW: its better to install the current ESR version ( https://www.mozilla.org/en-US/firefox/organizations/faq/ ) instead of going back to version 56 and turning off updates: https://www.mozilla.org/en-US/firefox/organizations/faq/ But I can understand you. All my clients now use the ESR version and if there is no solution till the ESR works, also there we have to disable updates and prevent clients from using FF to surf on the Web (then they use an old version of FF for the company-webapp and another browser for internet-surfing). Would not be a good case for Mozilla...
Just to be clear, the goal of WebExtensions is an API in a web browser to improve users interaction with web content. Supporting POS systems is not part of the goal for WebExtensions. Every feature we add has a cost on Mozilla in terms of development and maintenance so we evaluate each API. There are some improvements that around printing that have landed and perhaps there's a couple of APIs that could be split out from that bug. If you want to provide more sophisticated printing solutions or support POS systems, you might need to find a different solution other than Firefox. You can pass data through the nativeMessaging API which can do the printing for you, as an example. For the moment, we'll close the comments on this bug as it's currently not being productive.
(In reply to Shane Caraveo (:mixedpuppy) from comment #21) > > The first thing that's going to happen is splitting out the silent printing. > The other items are likely less contentious. The decision was made that > this could not be done without user interaction. It may be possible to > rethink how that is handled, but I think getting forward movement is going > to require that to be separate. > > I need to read through everything and get a good look at the experiment > before I can comment further. Is there some progress on issue?
You need to log in before you can comment on or make changes to this bug.