253926 - Print to file doesn't cancel properly

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Tommi Komulainen]

Take a long page, such as http://www.faqs.org/rfcs/rfc2616.html, start printing
to file (using PostScript/Default) and click Cancel.  Print progress dialog goes
away but printing continues in the background as can be observed from the file
size later (it takes a few minutes to finish.)

Furthermore, the should-be-incomplete file remains in the file system rather
than being removed.

Comment 1

[Jason Jackson]

I can verify this bug under Firefox 1.0.4 on Windows 2000 SP4.  It happens on
any page long enough to allow you to click cancel.  It happens every time.  But
wait, there's even more wrong here than the two things reported.

The "Cancel" button can sometimes become partially hidden when the url above it
is long.  You can watch the button get shifted over (to the right) till there's
next to nothing left of it.

And perhaps worst of all, if you do this while in the "Print Preview" mode, the
"Close" button will cease to function, leaving you pernamently in Print Preview
mode, leaving you with no option than to close Firefox, and re-open.

Comment 2

[Wayne Mery (:wsmwk)]

Tommi, do you still see this in linux?
jackson, did you do print to file or print to printer?

In windows...
* I do not see this printing to a file - it terminates promptly and nicely.
* printing to a printer it hangs the tab (or window if only one tab) when I cancel and the status of job in the print queue is "spooling", until browser application is closed. (Bug 297261)


(Jackson in comment #1)
> I can verify this bug under Firefox 1.0.4 on Windows 2000 SP4.  It happens on
> any page long enough to allow you to click cancel.  It happens every time.  

Jackson, see question above

 
> The "Cancel" button can sometimes become partially hidden when the url above it
> is long.  You can watch the button get shifted over (to the right) till there's
> next to nothing left of it.

jackson this is Bug 124203.  I don't see it on trunk. Do you still see this button movement in v1.5.0.4?

Comment 3

[Jason Jackson]

> jackson this is Bug 124203.  I don't see it on trunk. Do you still see this
> button movement in v1.5.0.4?

The problem with cancel button (mentioned only in my comment, not the bug report) is indeed the same as bug 124203 and seems to be resolved.

The bug (mention in the report description) still exists in 1.5.0.6.  I played around with it some more, and the following is a more detailed example.  If you go to a large page, enter print preview, and print using any method, you get a window with a progress bar and a cancel button.  If you click cancel, the window with the progress bar and cancel button will immediately go away.  However, if you try to click the close button to exit print preview, your tab bar will appear, but the print preview bar remains, and your menu bar, navigation bar, bookmarks bar (or whichever toolbars are enabled i'd assume) are missing.  I will attach a screenshot of this.  Now, if you wait long enough (to be specific, the time it would of taken if you hadn't clicked cancel and waited for the progress bar to reach 100%), you will then finally be able to click the close button in the preview bar, and everything will return to normal.  All of this is the case whether you're printing to file or a printer.  

Additionally if you're using the "Print to file" method, clicking cancel in the progress window does not stop generation of the file.  It will continue to grow in size until the progress bar would of reached 100%, and afterwards, the file remains there.  

I tested the same thing in an older version of Opera (8.52) I had, and it had more better results.  Opera would behave normally (you could immediately exit print preview after canceling) and the generation of the file would cease immediately, although it would keep an incomplete copy of the file there (I would expect/prefer standard behavior to remove any incomplete file).

Comment 4

[Jason Jackson]

I should mention that after you wait that length of time, the close button only works from the tab you originally were in print preview mode with.  As such, if you close that tab, and you want your toolbars back, you now are left with no option other than to completely exit from Firefox and start over.  Yikes!

Comment 5

[Jason Jackson]

Attachment: stuck in print preview mode

Comment 6

[Wayne Mery (:wsmwk)]

does this happen for you with trunk build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ 

behavior (hung in tab) is also similar to Bug 300347.

Comment 7

[Jason Jackson]

(In reply to comment #6)
> does this happen for you with trunk build?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ 
> 
> behavior (hung in tab) is also similar to Bug 300347.
> 

In Minefield 3.0a1, the problem still exists, but the symptoms have changed.  After printing, canceling, and clicking the the print preview bar's "close" button, it no longer makes the tab bar appear (at least no one will get stuck by closing the original print preview page anymore), however the close button is still unresponsive until you wait the time it would of taken if you hadn't clicked cancel.  In the case of this document on my modern system it's about 74 seconds.  Also, the generation of file still does not cease after clicking cancel.

Bug 300347 is definitely related to my problem with having tabs in print preview mode (although he got into that predicament through different means).  The means by which I got into that predicament do not exist in Minefield.  To clarify, the stuff mentioned in the previous paragraph is unrelated to Bug 300347.

Comment 8

[Leon Sha]

Attachment: Patch to fix on linux/unix platform.

This patch only provide the fix for linux/unix platform.
I don't know if the bug can also reproduced on windows.

Comment 9

[Kenneth Herron]

Comment on attachment 267235 [details] [diff] [review]
Patch to fix on linux/unix platform.

I'm not a reviewer for this component.

Comment 10

[Leon Sha]

Attachment: Add null check.

Comment 11

[Darin Fisher]

Comment on attachment 267363 [details] [diff] [review]
Add null check.

OK, looks good to me.  r=darin

However, I am not an expert on this code, so I could be missing something.  You should try to find a reviewer who understands Mozilla's printing UI.

Comment 12

[Leon Sha]

Checking in nsPrintProgress.cpp;
/cvsroot/mozilla/embedding/components/printingui/src/unixshared/nsPrintProgress.cpp,v  <--  nsPrintProgress.cpp
new revision: 1.10; previous revision: 1.9
done
Checking in nsPrintProgress.h;
/cvsroot/mozilla/embedding/components/printingui/src/unixshared/nsPrintProgress.h,v  <--  nsPrintProgress.h
new revision: 1.4; previous revision: 1.3
done
Checking in nsPrintingPromptService.cpp;
/cvsroot/mozilla/embedding/components/printingui/src/unixshared/nsPrintingPromptService.cpp,v  <--  nsPrintingPromptService.cpp
new revision: 1.17; previous revision: 1.16
done