Last Comment Bug 351581 - [Win] Print fails on first attempt but works on second
: [Win] Print fails on first attempt but works on second
Status: RESOLVED FIXED
[not needed beta][no l10n impact]
: relnote
Product: Calendar
Classification: Client Software
Component: Printing (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal with 20 votes (vote)
: 1.0b7
Assigned To: Philipp Kewisch [:Fallen]
:
Mentors:
: 360096 368465 434161 456760 544557 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-06 12:32 PDT by John
Modified: 2011-08-29 11:59 PDT (History)
33 users (show)
philipp: blocking‑calendar1.0+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
console output from win32 debug build (14.71 KB, text/plain)
2006-10-13 11:12 PDT, Stefan Sitter
no flags Details
patch for Bug 351581 (858 bytes, patch)
2010-05-31 01:50 PDT, Dimas
no flags Details | Diff | Review
Replacing "Cancel" with "Close" (1.14 KB, patch)
2010-06-16 19:19 PDT, Aleksandar
no flags Details | Diff | Review
Fix by hiding the window until printing is complete (71 bytes, patch)
2011-07-21 11:11 PDT, Philipp Kewisch [:Fallen]
no flags Details | Diff | Review
Fix by hiding the window until printing is complete (7.64 KB, patch)
2011-07-21 13:51 PDT, Philipp Kewisch [:Fallen]
no flags Details | Diff | Review
Fix - v3 (5.30 KB, patch)
2011-07-23 12:03 PDT, Philipp Kewisch [:Fallen]
bv1578: review+
Details | Diff | Review

Description John 2006-09-06 12:32:49 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060831 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060831 Firefox/1.5.0.7

I use Fine Print, a proprietary printer driver, to print. When I do so, Calendar fails to utilise this program. If I print directly to my Canon printer, printing is fine. Fine Print is a virtual printer but one that is used extensively at my work place. Thanks for your work. John

Reproducible: Always

Steps to Reproduce:
1. Try to print Calendar
2. Invoke Fine Print
3. The print function exits without Fine Print being started which it always does automatically.
Print directly to Canon printer = fine.

Actual Results:  
Fine Print not recognised by Calendar.

Expected Results:  
Fine Print should be recognised by Calendar.
Comment 1 Stefan Sitter 2006-09-06 12:36:31 PDT
Please specify version and build id of Calendar as shown in Help->About window.
Comment 2 Stefan Sitter 2006-09-07 08:18:31 PDT
2006/9/7, John Stafford <j_stafford@umanitoba.ca> wrote in email:

Version is : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060906 Calendar/0.3a2+
Comment 3 Matthew (lilmatt) Willis 2006-09-07 08:20:37 PDT
Could you provide some more detail as to how it fails?
Are there any error messages in the Error Console?

Thanks.
Comment 4 Sebastian Schwieger 2006-09-07 08:59:45 PDT
I see an issue which might be related:
1. use a Postscript Printer and install it to always print to file.
2. After pressing print in the print dialog, a dialog appears to enter a filename.
3. enter a filename, press enter
4. no file is produced!

Doing 2. - 3. a second time, produces the postscript file!

I think Fineprint is using a postscript driver, prints to a temporary file and then invokes the fineprint-program.

tested using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060905 Calendar/0.3a2+
Comment 5 Matthew (lilmatt) Willis 2006-09-07 09:12:35 PDT
Looking for more data points here:

Does anyone NOT on Windows see the "print fails silently on first try, but works on second" behaviour?
Comment 6 Stefan Sitter 2006-09-07 09:59:31 PDT
I can confirm this too on Win2k when printing to PDFCreator.
Sebo confirmed on irc that he saw this on WinXP with real printer.
Comment 7 Sebastian Schwieger 2006-09-09 08:18:35 PDT
apart from the problem reported in bug 351944 printing works on Suse9.3/Linux system with either postscript/default or real printer (CUPS driver) on first try.

using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060909 Calendar/0.3a2+
Comment 8 Sebastian Schwieger 2006-10-03 12:41:04 PDT
I vote for [cal relnote] on this issue.
Comment 9 geo. anderson 2006-10-13 07:41:24 PDT
I am seeing exactly the same thing.  Prints o.k. to my LJ4 PCL but nothing at all happens when I try to print to FinePrint.  Running 0.3 downloaded yesterday, XP Tablet patched more or less up to most current M$ stuff.
Comment 10 Matthew (lilmatt) Willis 2006-10-13 07:42:48 PDT
(In reply to comment #9)
> I am seeing exactly the same thing.  Prints o.k. to my LJ4 PCL but nothing at
> all happens when I try to print to FinePrint.

Can you print to FinePrint successfully using Firefox and Thunderbird?

Comment 11 geo. anderson 2006-10-13 07:48:44 PDT
Yes, all my apps print o.k including FireFox & Tbird.  Prior to this Sunbird issue, FinePrint has been a real solid citizen.  I actually use it as my default printer.  www.fineprint.com
Comment 12 Omar Bajraszewski 2006-10-13 08:39:14 PDT
I can confirm the bug because I use Fine Print too. No problems with other mozilla applications
Comment 13 Stefan Sitter 2006-10-13 11:12:29 PDT
Created attachment 242210 [details]
console output from win32 debug build

Attachment shows the console output from 20061012 Sunbird trunk build for the first attempt that fails and the seconds attempt that works. There are several warnings and assertions shown.
Comment 14 cmtalbert 2006-10-26 10:14:58 PDT
I can reconfirm this yet again, using my own sunbird 0.4 build from yesterday while testing the patch for bug 332063. It appears that the steps are simple and very reproducible.

This has been confirmed several times on windows. It has not been reported on other operating systems.

I recommend that we clear the QAWanted flag. 

If you disagree, please comment with what further is needed from QA.
Comment 15 Stefan Sitter 2006-11-09 09:34:24 PST
*** Bug 360096 has been marked as a duplicate of this bug. ***
Comment 16 Stefan Sitter 2006-11-19 04:44:59 PST
With todays win32 build I now see the following JS error on the first attempt:

Error: onUnload is not defined
Source File: chrome://global/content/printProgress.xul Line: 1
Comment 17 rac_ns 2007-01-17 05:20:04 PST
I noticed the same behaviour even without using a Software PostScript Printer. None of my HP Laserjets (tested on LJ 1100, 4000 and 4050) prints on the first attempt. I've tested PostScript, PCL5 and PCL6 drivers.
Comment 18 cmtalbert 2007-03-02 05:56:56 PST
*** Bug 368465 has been marked as a duplicate of this bug. ***
Comment 19 Matthew (lilmatt) Willis 2007-03-12 13:31:14 PDT
We can block 0.5 on this for now.
Comment 20 Matthew (lilmatt) Willis 2007-03-22 11:42:28 PDT
We're approaching code freeze for 0.5 with no patch and no assignee.
This no longer blocks.
Comment 21 Jim 2007-04-23 12:01:12 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20070213 Sunbird/0.3.1

Windows XP printing to a networked Minolta Copier using Fiery X3e 31C-M PS v1.2 driver.

No printing on first attempt.  Second attempt works.  No error msg displayed when fails to print first attempt.  It looks like it is going to the queue on first attempt but no joy.
Comment 22 Simon Paquet [:sipaq] 2007-08-09 09:27:35 PDT
Is this an issue on current 0.7pre Sunbird or Lightning nightlies?
Comment 23 Stefan Sitter 2007-08-09 10:50:10 PDT
(In reply to comment #22)

Fails with Sunbird 0.7pre (2007080905) and Lightning 0.7pre (2007080904) + Thunderbird 2.0.0.7pre (20070806) on Windows 2000.
Comment 24 Vaughn L. Reid III 2007-09-11 06:10:05 PDT
Using Sunbird version:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4pre) Gecko/20070614 Sunbird/0.5 on fully patched Windows XP Pro Service Pack 2

I can confirm that I am unable to print anything from Sunbird on the first try.  Printing attempts after the first attempt work fine.  

All my printers are either brother network laser and laserjet printers or the PDFCreator software version 0.9.3 available at http://sourceforge.net/projects/pdfcreator

Steps that I utilize to reproduce:
1.  Close Sunbird if it is open
2.  Open Sunbird by double-clicking desktop shortcut
3.  Click "File" -> "Print"
4.  In the print dialog that pops up enter a label, choose "List" layout, and select a custom date range
5.  Click print
6.  On the First attempt, nothing prints to any of my printers.  Subsequent print attempts while Sunbird is still open work as expected.
Comment 25 Richard Ireton 2007-10-25 17:30:41 PDT
I am also unable to print anything from Sunbird on the first try. 

Using Sunbird version: 0.7 one Dell PC with HP2355 printer and XP Home Sp2 wiith all updates.  Bug does not appear when using any other software.

Steps to reproduce:
1. Open Sunbird
2. Select PRINT under FILE to open PRINT PRIVIEW FRAME
3. Select MONTHLY GRID
4. Click on PRINT
5. Repeat steps 1 thru 4 before calendar will print
Comment 26 Simon Paquet [:sipaq] 2007-11-24 12:16:10 PST
Setting wanted0.8- as the main Calendar developers will not devote any time to
this in the 0.8 timeframe. Patches are, of course, always welcome.
Comment 27 Stefan Sitter 2008-05-17 09:29:43 PDT
*** Bug 434161 has been marked as a duplicate of this bug. ***
Comment 28 Arthur 2008-08-22 06:20:21 PDT
Happens also on 0.8 with Win XP and a brother laser printer.
Comment 29 Daniel Boelzle [:dbo] 2008-09-16 05:59:45 PDT
won't make 0.9
Comment 30 Stefan Sitter 2008-09-24 07:39:22 PDT
*** Bug 456760 has been marked as a duplicate of this bug. ***
Comment 31 racoon 2008-10-01 04:33:22 PDT
same problem here with Lightning 0.8 and 0.9 on Windows XP (SP3): printing fails on first attempt with all printer (Ricoh, Brother, Lexmark, PDF Creator ...)
Comment 32 Sebastian Schwieger 2008-10-02 04:47:45 PDT
Still happening with nightly comm-central builds. I also see the error mentioned in comment 16 on first attempt.
Comment 33 Bill Gianopoulos [:WG9s] 2008-12-05 16:51:35 PST
Changed Windows version to XP to make it a version that is actually still supported.  Also changed version to trunk as it still fails on current trunk and severity to major as printing is a major function.  I verified this issue does not exist under Linux.

This really needs to be fixed for Thunderbird 3.0/Lightning 1.0.

Even though there is no patch, and no one has any idea how to fix this, it should really be marked as blocking and help from people who know more about the mystery of the Mozilla printing code probably need to be enlisted to help fix this.
Comment 34 Stefan Sitter 2008-12-06 02:50:11 PST
Adjusting platform and severity because all users with Windows 2000 and higher are affected and there is an easy workaround available.
Comment 35 Bill Gianopoulos [:WG9s] 2008-12-06 12:49:28 PST
(In reply to comment #34)
> Adjusting platform and severity because all users with Windows 2000 and higher
> are affected and there is an easy workaround available.

Well, the use of the Windows version can be considered to be a difference between the way this field is used by this project and all other Mozilla projects.  In other Mozilla projects, bugs are list under versions of Windows that are no longer supported by Microsoft only if they do NOT occur in versions of Windows that are still supported by Microsoft.

However, The idea that this is not a major issue because just telling it to print again works is just absurd.  What actual user is ever going to guess that telling it to print again after it did not work the first time will actually produce results?

One of the definitions of insanity is to continue to perform the exact same action expecting different results.  Evidently Mozilla calendar is therefore the application designed for the insane.
Comment 36 Vaughn L. Reid III 2008-12-06 15:21:21 PST
I firmly believe that this bug needs to be a stopper for 1.0.  Being able to easily print by pushing the print button without having to perform workarounds is a fundamental function of desktop software on the Windows platform.  The majority of mozilla software, including calendar, is used on the Windows platform. 

 Therefore, Windows development should not take second place to the *nix platforms, if anything it should be a priority.  I have several customers who would love to be able to use Sunbird and Lightning, but until basic functionality, including printing, just works, it's not going to happen.  

The fact that this is a major usability issue and the fact that it just seems to get brushed off because Sunbird and Lightning print fine on the "cool" "bohemian" "anti-establishment" *nix versions is absolutely infuriating.
Comment 37 Ryan 2009-01-15 11:10:05 PST
I agree with Vaughn that this needs to be a stopper for 1.0.  I have been using Sunbird in an office environment with 30+ employees and printing is a vital function.  

I can tell you that this is very frustrating for the end user to have to do multiple prints to get one actual copy, especially if they are unaware of the bug.  This is further a hindrance with printers in a different office as an employee walks to a different part of the building only to find that they have to go back print and retrieve from printer again.
Comment 38 Philipp Kewisch [:Fallen] 2009-06-17 11:34:57 PDT
Wow, this bug is old. Martin, since you are on windows, maybe you can take a look at it?
Comment 39 Martin Schröder [:mschroeder] 2009-06-21 09:11:27 PDT
(In reply to comment #38)
> Wow, this bug is old. Martin, since you are on windows, maybe you can take a
> look at it?

I could reproduce, and can confirm (after adding some debugging output) that PrintUtils.print() is called for the first attempt to print without throwing an exception. But I do not know how to proceed from here. Re-assigning to nobody@m.o!
Comment 40 Vaughn L. Reid III 2009-10-05 12:52:25 PDT
I have received some error messages inside of Sunbird error console on a Windows computer when trying to print for the first time upon opening a Sunbird instance.  I'm using the 10/5/2009 nightly of Sunbird for Win32 on a Vista machine.

I cleared out all of the error messages in the console and then tried to print.  I received 2 messages.  They are listed here:

First Message:
File Read Error (underflow.) (file:///C:/Program%20Files/Calendar/calendar-js/)
file:///C:/Program%20Files/Calendar/modules/calUtils.jsm   Line:80

Second Message:
File Read Error (underflow.) (file:///C:/Program%20Files/Calendar/calendar-js/)
file:///C:/Program%20Files/Calendar/modules/calUtils.jsm   Line:80

When I click on the hyperlink in the error message, it takes me to some code that looks like its reading an array of various utility scripts from a different calendar file.

If I clear out the error console and try to print the calendar again, the printing is successful and these two error messages are not repeated (instead there are several different messages listed).

This leads me to believe that these two error exceptions are the core problem  with the initial print failure of calendars on a win32 system.

Steps needed to reproduce errors:
1.  Download and install the nightly Sunbird build for win32 from mozilla on a windows desktop pc
2.  Have one or more printers installed on this desktop pc
3.  Place some data into one or more calendars in Sunbird
4.  Open Sunbird
5.  Open the error console at Tools --> error console and erase existing error messages
6.  Click File --> print and accept the default print dialog box settings
7.  Press the print button
8.  Review the Error Console.  The two errors listed above should be visible.
9.  Clear the Error Console
10.  Print the calendar again
11.  This time a few completely different error messages will be listed.
Comment 41 Stefan Sitter 2009-10-05 13:10:17 PDT
(In reply to comment #40)
> File Read Error (underflow.) ...

This issue is filed as Bug 512780 and unrelated to the print issue.
Comment 42 Vaughn L. Reid III 2009-10-05 13:13:07 PDT
Thanks for the clarification.
Comment 43 Jessica 2010-05-05 10:11:11 PDT
Hi all, 

Has there been a patch for the print issue? I can't believe it has been going on for four years. I am having the same issue -- except it doesn't always print on the second attempt. Sometimes it takes three, maybe four tries.

I work as the HR coordinator for 4 different offices. One of the offices as a whole is not very computer literate, and this issue is frustrating them to no end. Sunbird is easily the best calendar program out there, except for this print issue. If there are any updates on how to fix this easily I would really appreciate knowing where to find them. Otherwise I'm going to have to find them a different program that prints their calendars.

Thank you so much for your help!
Comment 44 Vaughn L. Reid III 2010-05-06 06:48:31 PDT
Is there any way to speed up getting this issue fixed?  This printing issue makes both Lightning and Sunbird virtually unusable for the vast number of "normal level" Windows users because they either don't understand the workaround or find the bug so annoying and unacceptable that they would rather use a different piece of software.  

For those of us who donate to the Mozilla Foundation, can we direct our donations towards fixing this issue?  Is there a bounty system in place?  

Are there even any plans to fix this major usability issue?  Having dealt with this problem personally for the last three+ years, I find it annoying, and I'm an open source advocate and very technically inclined.  Most people aren't either so this bug is a show stopper for them.

Please fix this bug.
Comment 45 Philipp Kewisch [:Fallen] 2010-05-06 07:04:57 PDT
Vaughn, I'm sorry this is bugging you. I unfortunately don't have a windows machine to test this, and I can imagine other developers have similar problems. Also we have a lot of other more critical bugs, so that this one needs to be postponed until we have more time. Nevertheless, I do hope this issue is fixed soon!
Comment 46 geo. anderson 2010-05-06 07:52:39 PDT
> we have a lot of other more critical bugs

Phillipp, I am a user not a contributor so I try not to complain about the free lunch.  But I do question the team's priority-setting system if this is not considered a "critical" bug.  I would humbly assert that many more of T'bird/Calendar's users and potential users will try to print than will be worried about things like "Some languages need weekdays in plural form for some sentences in Recurrence Summary" or "Query for supported-calendar-component-set in case servers don't support tasks/events," both of which were fixed in the last release.

We all have an interest in T'bird's success. To ignore a bug like this, which is apparent to _all_ users, makes the product look amateurish and incomplete to the majority of unsophisticated users -- in other words, to the _real_ T'bird/calendar market.
Comment 47 Philipp Kewisch [:Fallen] 2010-05-06 08:16:54 PDT
(In reply to comment #46)
As you've already mentioned, the project is based on contributions from the community. If someone decides to fix a bug (like the weekdays in plural form bug), then we won't deny because he should have focused on a printing bug. Also as you can see, the bug you mentioned took 9 months to be reviewed and checked in, so you can see it didn't have really high priority.

Regarding the supported-calendar-component-set bug, fixing this bug means that having a Google Calendar via caldav selected will not allow creating tasks. Tasks are a much more central concept of the calendar, so this bug has higher priority.

It may certainly happen that bugs with lower priority are done before bugs with higher priority, but I do hope that in most cases we are concentrating on bugs that are important.

Personally, I have been neglecting the bug because of lack of a set up windows build environment and the fact that just trying to print again causes it to work. From what I've seen with casual users, if they see something obvious like File > Print and it doesn't seem to work, they just try again because they think they didn't click right.

I'm happy to take patches and/or debug info on this bug, but unless someone steps up this will unfortunately not happen for the next release.
Comment 48 Dimas 2010-05-31 01:50:07 PDT
Created attachment 448347 [details] [diff] [review]
patch for Bug 351581

I think this patch resolve the problem.
Comment 49 Ed Davis 2010-05-31 19:31:19 PDT
Thanks Dimas,

This fixed the bug on my Windows XP box.  Amazing to see the solution is a very few lines of code ... essentially just change "closeDialog = true" to "closeDialog = false".

Ed
Comment 50 Ed Davis 2010-06-01 04:01:47 PDT
Not sure I implemented the patch exactly right.  The printing bug is fixed.  I noticed a new bug with this patch in that the "Print Preview" dialog window does not close after clicking on "Print".  I can close the dialog by clicking "Cancel" after I am finished printing.  It seems like the window should close automatically.  Do we have a choice between two bugs?

Ed
Comment 51 Cedric 2010-06-01 13:52:31 PDT
Perhaps we can just set a delay before closing the print preview dialog ?
The following code works for me :


function printAndClose() {
  refreshHtml(
    function finish() {
      PrintUtils.print();
      // cancel the dialog window after 1 second
      setTimeout('document.getElementById("calendar-new-printwindow").cancelDialog()', 1000);
      });
  return false; // leave open
}
Comment 52 Dimas 2010-06-02 00:40:16 PDT
(In reply to comment #50)
> Not sure I implemented the patch exactly right.  The printing bug is fixed.  I
> noticed a new bug with this patch in that the "Print Preview" dialog window
> does not close after clicking on "Print".  I can close the dialog by clicking
> "Cancel" after I am finished printing.
That's how it works in Linux. Are you sure this is a bug?

> It seems like the window should close automatically.  Do we have a choice 
> between two bugs?
> 
> Ed

Dimas
Comment 53 Vaughn L. Reid III 2010-06-02 05:36:52 PDT
On the Windows platform, after a person presses the print button, the print preview dialog window should automatically close in order to be consistent with the way other Windows applications work.
Comment 54 Ed Davis 2010-06-02 14:12:53 PDT
> That's how it works in Linux. Are you sure this is a bug?

Good point, Dimas.  The Print Preview in Mozilla Firefox behaves this way on my Windows XP box.

After some reflection I find it convenient when the Print Preview window is left open.  With the window remaining open it requires fewer steps to then print another day.

The Cancel button seems a little awkward after having successfully printed.  I notice that Print Preview in Mozilla Firefox does not have a Cancel button but instead has a Close button.  

I suggest renaming the "Cancel" button in Sunbird Print Preview as "Close" so it will be more similar to Mozilla Firefox.  

With Vaughn's comment in mind it might be a good exercise to take a peek at the Print Preview behavior of some other Mozilla apps just in case Firefox is an odd case.  Consistency with other Mozilla apps would be a good guide here.

Ed
Comment 55 Vaughn L. Reid III 2010-06-02 14:40:11 PDT
I noticed, after I made my post this morning, that Firefox stays open with it's print preview after printing.  Unfortunately, I didn't have time to make another comment until now.  

I agree with Ed that consistency with the way print previews work across various Mozilla applications should be the goal. And I think it is wise to replace the word "Cancel" on the right hand button with "Close" to increase consistency with other Mozilla applications.

I just checked and Thunderbird's print preview behaves just like the Firefox print preview in that the preview stays up until you click close.

It seems that the Lightning/Sunbird print preview may use a different print preview engine than Thunderbird and Firefox because because its (lightning/sunbird) preview looks way different.  Is it possible to have the Lightning/sunbird print preview to mimic Thunderbird/Firefox's print preview?

Also, I'd like to express my appreciation that this issue seems to be well on the way to being resolved.  It makes it much easier for all of us Windows users to be able to recommend the Thunderbird/Lightning combination to clients, customers, friends, and family as a serious task management product when the printing just works.  And once this printing resolution is finalized, it will add a layer of polish and professionalism to the Tunderbird/Lightning combination when people use it.  Thank you :-)

One Last thing:  Is the test fix available in a build that is compatible with Thunderbird 3.0.4?
Comment 56 Ed Davis 2010-06-02 17:04:28 PDT
> replace the word "Cancel" on the right hand button with "Close"

Above and the patch by Dimas should be priority for calendar 1.0

> print preview to mimic Thunderbird/Firefox's

I think this would be great in calendar 1.0.  Not worth delaying calendar 1.0.  Should become priority after 1.0 has been released.

Ed
Comment 57 Ed Davis 2010-06-02 18:10:44 PDT
>> replace the word "Cancel" on the right hand button with "Close"

>Above and the patch by Dimas should be priority for calendar 1.0

Above is essentially a duplicate of bug 377414
_________________________

>> print preview to mimic Thunderbird/Firefox's

> I think this would be great in calendar 1.0.
> Not worth delaying calendar 1.0. 
> Should become priority after 1.0 has been released.

This print preview discussion should probably be continued at bug 350099
Comment 58 Bas van den Bosch 2010-06-03 22:14:12 PDT
Essentially what Dimas did in the patch was settig the close-action for windows to false, like it, according to the code, was on unix and linux. So the discussion should be kept here. The question is why, before the patch, you had to press print twice. This isn't solved. Does setting the time-out work?
Comment 59 Ed Davis 2010-06-04 13:45:30 PDT
> This isn't solved. Does setting the time-out work?

Comment 51 above states that the time-out works for Cedric.

This was never solved on Linux back in 2007.  In 2007 the interim solution for the Linux printing problem was to keep the print dialog open.  I vote to implement the same interim solution for Windows.  Admittedly, the use of the word interim is dubious in the year 2010. ;-)

Part of me wonders if this issue might be addressed in Mac OSX in 2013. ;-)

=======
See bug 351957 comment 26
https://bugzilla.mozilla.org/show_bug.cgi?id=351957#c26
Keeping the dialog open works to avoid "cannot print while in print preview" on
Unix. We all know that this doesn't fix the root cause, which I assume lies in
the PS printing core of the toolkit. However, unless that has been fixed, IMO
it's a sensible interim solution on Unix.


Other relevant comments:

https://bugzilla.mozilla.org/show_bug.cgi?id=351944#c2
https://bugzilla.mozilla.org/show_bug.cgi?id=351957#c7
https://bugzilla.mozilla.org/show_bug.cgi?id=351944#c9
https://bugzilla.mozilla.org/show_bug.cgi?id=351957#c11
https://bugzilla.mozilla.org/show_bug.cgi?id=351957#c30
Comment 60 Bas van den Bosch 2010-06-05 09:56:40 PDT
I meant to say I wondered wether the time-out would also work on linux/unix... If so I'd like to suggest also putting in an extra second there...
Comment 61 Cedric 2010-06-06 11:48:46 PDT
(In reply to comment #60)
> I meant to say I wondered wether the time-out would also work on linux/unix...
> If so I'd like to suggest also putting in an extra second there...

Well, finally, I think adding a delay before closing the dialog is just an ugly workaround ...
The one second delay works for me on my recent computer with Windows Seven, but there is no warranty that it will work on all platforms and hardware.

I also vote for implementing the following solution, for all platforms :
- leave the print preview dialog open
- replace the 'Cancel' button by 'Close'
This solution will unify the 'print preview dialog' behaviour across all Mozilla softwares and all platforms.
And it will (finally) close both bug 377414 and this bug 351581 !
Comment 62 Aleksandar 2010-06-16 19:19:53 PDT
Created attachment 451796 [details] [diff] [review]
Replacing "Cancel" with "Close"

I agree, adding delay after printing is an ugly workaround and mostly delays are bad way of solving problems.
If the print dialog is going to stay after printing I think button "Close" should be placed instead of "Cancel" button, as it was earlier said, there is nothing to be canceled after successful printing.If nothing else is going to be printed the window should be "closed".
I have uploaded the fix for changing Cancel to Close..
Comment 63 Philipp Kewisch [:Fallen] 2010-06-17 00:59:08 PDT
Just a quick idea: The Problem is that something in the dialog needs to stay open so the print can complete. Can't we move this something into either a hidden window, or the opener window?
Comment 64 Dimas 2010-06-17 01:13:41 PDT
I think leave the print preview dialog open and replace the 'Cancel' button by 'Close', is a good solution.
Comment 65 Laurent Bauvens 2010-06-24 02:51:00 PDT
It's a very annoying bug for people like assistants in businesses who manage calendar for executives and need to print often.

I think this is typically a (little?) bug which could slow down Lightning deployment in businesses at the profit of MS Outlook.

Thanks
Comment 66 Ken Anderson 2010-09-06 02:46:06 PDT
Re: the patch posted by Dimas on 2010-05-31, could anyone please explain how to actually use it (sorry I am not a programmer, I tried to copy-paste the code in txt, rename it as .js and run it in the SunBird directory, but it didn't work...)

Thanks again for the efforts spent in trying to solve this annoying issue!
Comment 67 David Carlson 2010-10-09 08:47:30 PDT
Hi,

Just to add fuel to the fire, I am using foxyproxy to route e-mail through Polipo on localhost:8118.  My system is Windows XP SP3 and I have Thunderbird 3.1.4 with Calendar.  Thunderbird can print e-mails to a printer on my local network, but when I try to print a calendar, the print request goes to Foxyproxy/Polipo and I get the error 504 Connect to 192.168.1.45:80 failed: General SOCKS server failure from polipo.
Comment 68 Arthur 2010-10-09 09:53:08 PDT
Hi David. Your bug seems to be completely unrelated to this one. Please search for a fitting existing bug or file a new one. Thanks.
Comment 69 Cedric 2010-10-12 14:50:33 PDT
What's exactly the status of this bug ?
Are we still waiting for a review of the patch done by Dimas, five months ago ?
Comment 70 Philipp Kewisch [:Fallen] 2010-10-13 14:32:38 PDT
Comment on attachment 448347 [details] [diff] [review]
patch for Bug 351581

I'd appreciate if someone could look into my idea from comment 63, which I think would be a cleaner solution for both unix and windows. I'm sorry this patch hasn't had review yet, but to me its just another workaround that the dialog is not closed.
Comment 71 Rainer Glaschick 2010-10-14 00:31:42 PDT
(In reply to comment #70)

> I'd appreciate if someone could look into my idea from comment 63, which I
> think would be a cleaner solution for both unix and windows. I'm sorry this
> patch hasn't had review yet, but to me its just another workaround that the
> dialog is not closed.

Yes, that is a technically a kind of workaround, unless the root cause is resolved, which is somewhere deeper in the PrintUtils used. While I have not yet any sound knowlege about the structure of this system, I have the impression that this is a wrong synchronisation within the printing code, see below. 

Nevertheless, not closing the window would be consistent in the UI sense, as the window is of the preview kind, which are always left open in the rest of the mozilla system. Only if printing is straight without options, no window remains open - because none has be displayed.

And a hidden window would not help, because the problem is how to know when to close that hidden window. If you could tell when to close, the closing of the preview window could be postponed until this event occurs. But as far as I could see, the call of 'PrintUtils.print();' is presumed to be synchronous, but it obviously is not. 

As I have just found out, the same effect occurs not only with FinePrint (which I use also), but with the TinyPDF virtual printer too. Thus, I think it is really a bug within the printing interface, that is, however, still to be pinned down.

In any case, the fairly simple way of not closing the print preview window and changing the labels to 'print' and 'close' has still a chance to be added to 1.0b3, so thats what I would prefer. I am currently testing it for my copy of 1.0b2 and could supply diffs with actual line numbers, but I have not yet enough experience with the mozilla project to apply the changes myself or have the patch reviewd.
Comment 72 Cedric 2010-10-16 08:19:21 PDT
I totally agree with Rainer's comments.

I can also add that this bug also happens with PDFCreator and with different kind of HP printers, connected on a LAN.

We are using Sunbird / Lightning at work, and I'm just tired to hear people complaining that 'printing the calendar' does no work ...
I really hope this simple fix can be accepted as soon as possible ...
Comment 73 Dan Azlin 2010-11-02 16:51:08 PDT
FYI, I have observed this bug on my workstation running XPPro SP3 with Lightning V1.0b2 as well as all previous versions of the add-on. I am currently running Tunderbird 3.16. The behavior replicates on all print drivers when printing from Lightning, but does not occur when printing from Thunderbird. In my case, the first print attempt has no effect (it doesn't reach the Win print spooler) but the second attempt works fine. 

My thought is that the print job is not being set up correctly prior to the request being sent to the OS print service... or the 1st print request succeeds only in resetting the print service to accept the next print request... HTH
Comment 74 David Carlson 2010-11-14 17:56:09 PST
Hi,

Since Thunderbird prints correctly in a Windows environment, either going through the preview step or skipping it, then it seems to me that the easiest solution is to copy most of the Thunderbird code, except for calendar specific formatting.

Am I missing something?
Comment 75 Stefan Sitter 2011-02-01 12:44:36 PST
*** Bug 544557 has been marked as a duplicate of this bug. ***
Comment 76 Jochen 2011-02-20 20:10:48 PST
This print-the-document-at-the-second-try-bug also appears with FreePDF as virtual printer.
There are three entries in the Error Console after trying to print (the 3rd one needs a while till it appears):

1) Fehler: File Read Error (underflow.) (file:///C:/Program%20Files%20(x86)/Mozilla%20Sunbird/calendar-js/)
Quelldatei: file:///C:/Program%20Files%20(x86)/Mozilla%20Sunbird/modules/calUtils.jsm
Zeile: 80

2) Equal to the 1st one.

3) Fehler: [Exception... "Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIDocShellHistory.useGlobalHistory]"  nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)"  location: "JS frame :: chrome://global/content/bindings/browser.xml ::  :: line 643"  data: no]
Quelldatei: chrome://global/content/bindings/browser.xml
Zeile: 647


---
Version information: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.5) Gecko/20091211 Sunbird/1.0b1
Comment 77 Stefan Sitter 2011-02-21 00:19:57 PST
> 1) Fehler: File Read Error (underflow.)

Already fixed last year with Bug 512780 and not related to the bug here.

> Version information: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.5)
> Gecko/20091211 Sunbird/1.0b1

Please keep in mind that Sunbird is no longer being developed. I therefore recommend to always retest with the latest Lightning build.
Comment 78 David Carlson 2011-02-21 14:18:14 PST
This bug has been open for over 4 years now.  	Dimas, are you working on it?
Comment 79 Dimas 2011-02-22 00:38:18 PST
No, leave the print preview dialog open and replace the 'Cancel' button by
'Close', is a good solution for me.
Comment 80 Philipp Kewisch [:Fallen] 2011-07-21 11:11:28 PDT
Created attachment 547446 [details] [diff] [review]
Fix by hiding the window until printing is complete

This is what I've come up with. Tested on mac, other platforms pending.
Comment 81 Paul Gritt 2011-07-21 11:43:42 PDT
I don't understand your fix.  Hide which window??
Windows 7
Comment 82 Philipp Kewisch [:Fallen] 2011-07-21 11:55:00 PDT
Calendar Print Dialog is shown, you select print. The OS print dialog shows up, you select ok. The calendar print dialog gets hidden, but not closed. The printing completes, the calendar print dialog is closed.
Comment 83 Martin Schröder [:mschroeder] 2011-07-21 13:42:45 PDT
Comment on attachment 547446 [details] [diff] [review]
Fix by hiding the window until printing is complete

The diff seems to be empty, or is it just me?
Comment 84 Philipp Kewisch [:Fallen] 2011-07-21 13:51:33 PDT
Created attachment 547499 [details] [diff] [review]
Fix by hiding the window until printing is complete

Ah, now I get it! Thanks for the note. Hope this works better
Comment 85 Paul Gritt 2011-07-22 05:49:17 PDT
Sorry I still don't get this fix

I open the calendar print dialog
select weekly Planner,
Select "print"
The windows print dialog box opens
I select OK and both boxes close but nothing prints.
do this the second time and the calendar prints.

can you explain what I am doing wrong??

Thanks
Comment 86 Paul Gritt 2011-07-22 05:52:41 PDT
Comment on attachment 547499 [details] [diff] [review]
Fix by hiding the window until printing is complete

I guess I don't understand how to use this patch??

Please explain what I need to do for the patch to work??

Thanks
Comment 87 Philipp Kewisch [:Fallen] 2011-07-22 05:56:47 PDT
Paul, you need to apply the code to your local installation or wait until its reviewed and fixed and in the nightly builds.
Comment 88 Philipp Kewisch [:Fallen] 2011-07-23 12:03:05 PDT
Created attachment 547944 [details] [diff] [review]
Fix - v3

Ok, after testing on windows I've decided to just leave the preview dialog open until printing completes. This doesn't mean the dialog blocks anything, but it will stay open during the OS dialog that sends the page(s) to the printer. This usually take a second at most.
Comment 89 Philipp Kewisch [:Fallen] 2011-07-23 12:04:29 PDT
We should block 1.0 on this, since it already has a patch and might scare off windows users.
Comment 90 Decathlon 2011-08-05 01:56:05 PDT
Comment on attachment 547944 [details] [diff] [review]
Fix - v3

It works fine with this behavior (Win7)

1. open the print preview dialog;
2. click the print button;
3. OS print dialog appears;
3. click OK button;
4. a printing progress window appears (OS print dialog disappears);
5. print preview dialog disappears AND printer starts.

Reading previous comments, someone wanted the preview dialog stays open after printed, and close the dialog only with the "cancel" (or "close") button. I don't know what's better. Probably the most common case is printing only one document, so this behavior should be fine, but I understand those that want to print more documents and with different settings every time.

In Thunderbird and Firefox the preview window is always left open, but they have the "print" and the "print preview" options. The first opens the OS print dialog directly, the second opens the preview window where settings can be changed and this is the Lightning case.
Maybe there is a bit of inconsistency with the Mozilla system, but this should be another bug.     


The code needs only to delete the "canceled" variable that I didn't understand what was for until I saw the previous patch (it should be a not deleted part of the previous patch, is it right?).

r+
Comment 91 Philipp Kewisch [:Fallen] 2011-08-05 11:16:57 PDT
(In reply to Decathlon from comment #90)
> Reading previous comments, someone wanted the preview dialog stays open
> after printed, and close the dialog only with the "cancel" (or "close")
> button. I don't know what's better. Probably the most common case is
> printing only one document, so this behavior should be fine, but I
> understand those that want to print more documents and with different
> settings every time.
As I understood it, this was though of as a workaround since the printing didn't seem to work with the dialog closed.


> In Thunderbird and Firefox the preview window is always left open, but they
> have the "print" and the "print preview" options. The first opens the OS
> print dialog directly, the second opens the preview window where settings
> can be changed and this is the Lightning case.
> Maybe there is a bit of inconsistency with the Mozilla system, but this
> should be another bug.
I don't think its a bad thing to be different here. In comparison to Firefox we don't have a full fledge browser window that needs previewing and our print preview is also slightly different.
    
> The code needs only to delete the "canceled" variable that I didn't
> understand what was for until I saw the previous patch (it should be a not
> deleted part of the previous patch, is it right?).
Good catch! I'll remove the canceled variable before checkin.
Comment 92 Philipp Kewisch [:Fallen] 2011-08-05 12:16:25 PDT
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/9cf88871ec09>

-> FIXED
Comment 93 Philipp Kewisch [:Fallen] 2011-08-29 11:59:36 PDT
This bug was also pushed to comm-beta and comm-aurora, likely during the last merge.

Note You need to log in before you can comment on or make changes to this bug.