Closed Bug 351581 Opened 18 years ago Closed 13 years ago

[Win] Print fails on first attempt but works on second

Categories

(Calendar :: Printing, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: j_stafford, Assigned: Fallen)

References

Details

(Whiteboard: [not needed beta][no l10n impact])

Attachments

(2 files, 4 obsolete files)

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.
Please specify version and build id of Calendar as shown in Help->About window.
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+
Could you provide some more detail as to how it fails?
Are there any error messages in the Error Console?

Thanks.
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+
Looking for more data points here:

Does anyone NOT on Windows see the "print fails silently on first try, but works on second" behaviour?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
I can confirm this too on Win2k when printing to PDFCreator.
Sebo confirmed on irc that he saw this on WinXP with real printer.
OS: Windows XP → Windows 2000
Summary: Printing to Fine Print fails. → Print fails on first attempt but works on second
Version: unspecified → Trunk
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+
I vote for [cal relnote] on this issue.
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.
(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?

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
I can confirm the bug because I use Fine Print too. No problems with other mozilla applications
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.
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.
Keywords: qawanted
*** Bug 360096 has been marked as a duplicate of this bug. ***
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
Flags: blocking-calendar0.5?
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.
We can block 0.5 on this for now.
Flags: blocking-calendar0.5? → blocking-calendar0.5+
We're approaching code freeze for 0.5 with no patch and no assignee.
This no longer blocks.
Flags: blocking-calendar0.5+ → blocking-calendar0.5-
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.
Summary: Print fails on first attempt but works on second → [Win] Print fails on first attempt but works on second
Flags: blocking-calendar0.7?
Is this an issue on current 0.7pre Sunbird or Lightning nightlies?
(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.
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.
Keywords: relnote
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
Flags: wanted-calendar0.8?
Flags: blocking-calendar0.7?
Flags: blocking-calendar0.5-
Version: Trunk → unspecified
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.
Flags: wanted-calendar0.8? → wanted-calendar0.8-
Happens also on 0.8 with Win XP and a brother laser printer.
Flags: wanted-calendar0.9?
Flags: wanted-calendar0.8-
won't make 0.9
Flags: wanted-calendar0.9? → wanted-calendar0.9-
Flags: blocking-calendar1.0?
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 ...)
Still happening with nightly comm-central builds. I also see the error mentioned in comment 16 on first attempt.
Severity: normal → major
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.
OS: Windows 2000 → Windows XP
Version: unspecified → Trunk
Adjusting platform and severity because all users with Windows 2000 and higher are affected and there is an easy workaround available.
Severity: major → normal
OS: Windows XP → Windows 2000
(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.
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.
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.
Wow, this bug is old. Martin, since you are on windows, maybe you can take a look at it?
Assignee: nobody → mschroeder
Flags: wanted-calendar1.0+
(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!
Assignee: mschroeder → nobody
Flags: wanted-calendar0.9-
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.
(In reply to comment #40)
> File Read Error (underflow.) ...

This issue is filed as Bug 512780 and unrelated to the print issue.
Thanks for the clarification.
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!
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.
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!
> 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.
(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.
Attached patch patch for Bug 351581 (obsolete) — Splinter Review
I think this patch resolve the problem.
Attachment #448347 - Flags: review?(mschroeder)
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
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
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
}
(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
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.
> 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
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?
> 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
>> 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
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?
> 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
Assignee: nobody → dimassevfc
Status: NEW → ASSIGNED
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...
(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 !
Attached patch Replacing "Cancel" with "Close" (obsolete) — Splinter Review
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..
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?
I think leave the print preview dialog open and replace the 'Cancel' button by 'Close', is a good solution.
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
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!
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.
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.
What's exactly the status of this bug ?
Are we still waiting for a review of the patch done by Dimas, five months ago ?
Attachment #448347 - Flags: feedback?
Attachment #448347 - Flags: approval1.9.2.12?
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.
Attachment #448347 - Flags: feedback?
Attachment #448347 - Flags: approval1.9.2.12?
(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.
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 ...
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
Attachment #451796 - Attachment is patch: true
Attachment #451796 - Attachment mime type: application/octet-stream → text/plain
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?
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
> 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.
This bug has been open for over 4 years now.  	Dimas, are you working on it?
No, leave the print preview dialog open and replace the 'Cancel' button by
'Close', is a good solution for me.
Status: ASSIGNED → NEW
This is what I've come up with. Tested on mac, other platforms pending.
Assignee: dimassevfc → philipp
Attachment #448347 - Attachment is obsolete: true
Attachment #451796 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #448347 - Flags: review?(mschroeder)
I don't understand your fix.  Hide which window??
Windows 7
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 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?
Ah, now I get it! Thanks for the note. Hope this works better
Attachment #547446 - Attachment is obsolete: true
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 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
Paul, you need to apply the code to your local installation or wait until its reviewed and fixed and in the nightly builds.
Attached patch Fix - v3Splinter Review
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.
Attachment #547499 - Attachment is obsolete: true
Attachment #547944 - Flags: review?(bv1578)
We should block 1.0 on this, since it already has a patch and might scare off windows users.
Flags: wanted-calendar1.0+
Flags: blocking-calendar1.0?
Flags: blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact][needs review]
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+
Attachment #547944 - Flags: review?(bv1578) → review+
(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.
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/9cf88871ec09>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [not needed beta][no l10n impact][needs review] → [not needed beta][no l10n impact]
Target Milestone: --- → Trunk
This bug was also pushed to comm-beta and comm-aurora, likely during the last merge.
Target Milestone: Trunk → 1.0b6
You need to log in before you can comment on or make changes to this bug.