Printing a PDF via print preview doesn't work

RESOLVED FIXED in mozilla26

Status

()

Core
Layout
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: JK, Assigned: bdahl)

Tracking

({regression, reproducible})

18 Branch
mozilla26
x86
Windows 7
regression, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox19 affected, firefox20+ wontfix, firefox21+ wontfix, firefox22+ wontfix, firefox23- affected)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
If you try to print a PDF via print preview, a message box "An unknown error occurred while printing" pops up, and the print preview goes white and cannot be closed.

This is the error when attempting to close the preview.

Timestamp: 23.2.2013 19:26:19
Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebBrowserPrint.exitPrintPreview]
Source File: chrome://global/content/printUtils.js
Line: 258
(Reporter)

Updated

5 years ago
Severity: normal → major
(Reporter)

Comment 1

5 years ago
This doesn't happen with every PDF. See the URL for an example that triggers the bug.

Comment 2

5 years ago
There is a regression range:
m-c
good=2012-10-03
bad=2012-10-04
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=635fcc11d2b1&tochange=4cb8f88213f5
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
Version: Trunk → 18 Branch

Comment 3

5 years ago
Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/6e04928c99aa
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121002190616
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/24b61485c945
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121002190917
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6e04928c99aa&tochange=24b61485c945

Triggered by:
fe034183d766	Brendan Dahl — Bug 789507 - Add watchdog for mozPrintCallbacks. r=smaug
Blocks: 789507
Component: PDF Viewer → Layout
Keywords: regressionwindow-wanted
Product: Firefox → Core

Updated

5 years ago
tracking-firefox20: --- → ?
tracking-firefox21: --- → ?
tracking-firefox22: --- → ?
It would be great to have a fix for this in 20, tracking.
Assignee: nobody → bdahl
status-firefox20: --- → affected
status-firefox21: --- → affected
status-firefox22: --- → affected
tracking-firefox20: ? → +
tracking-firefox21: ? → +
tracking-firefox22: ? → +

Comment 5

5 years ago
Is this a platform specific issue? If not, please update the platform attributes. Thanks!

Updated

5 years ago
status-firefox19: --- → affected
This will have to miss FF20 since it's too late for speculative fixes now and we're not seeing any movement here.
status-firefox20: affected → wontfix
(Assignee)

Comment 7

5 years ago
This patch was rather large and had follow up fixes that we'd also need to merge.  I would rather not uplift for FF21 and just let it ride trains and be fixed in FF22.
(Assignee)

Comment 8

5 years ago
(In reply to Brendan Dahl from comment #7)
> This patch was rather large and had follow up fixes that we'd also need to
> merge.  I would rather not uplift for FF21 and just let it ride trains and
> be fixed in FF22.

Sorry comment was intended for bug 799695
(In reply to Brendan Dahl from comment #8)
> (In reply to Brendan Dahl from comment #7)
> > This patch was rather large and had follow up fixes that we'd also need to
> > merge.  I would rather not uplift for FF21 and just let it ride trains and
> > be fixed in FF22.
> 
> Sorry comment was intended for bug 799695

So do we have an upcoming patch here to help with this Bug in Fx21 timeframe ?
(Assignee)

Comment 10

5 years ago
This may just be that we need to increase the timeout for the printing watchdog.  Let me try that and if that doesn't fix it I'll re-assign since there are probably people better suited to look into this than me.
(Assignee)

Comment 11

5 years ago
I'm unable to reproduce with virtual machine with Windows 7 FF20 or FF23 and also a hardware accelerated machine.  Is this still an issue?
Flags: needinfo?(spammaaja)
Given we were unable to reproduce this based off comment 11, I am going to change the tracking/status flags accordingly.

Feel free to renominate if this is reproducible.

Updated

5 years ago
status-firefox21: affected → unaffected
status-firefox22: affected → unaffected
tracking-firefox21: + → -
tracking-firefox22: + → -

Comment 13

5 years ago
(In reply to bhavana bajaj [:bajaj] from comment #12)
> Given we were unable to reproduce this based off comment 11, I am going to
> change the tracking/status flags accordingly.
> 
> Feel free to renominate if this is reproducible.


I can still reproduce.
http://hg.mozilla.org/mozilla-central/rev/1150403342b2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130422 Firefox/23.0 ID:20130422105838
http://hg.mozilla.org/releases/mozilla-aurora/rev/5ab3070be609
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130422 Firefox/22.0 ID:20130422004013
http://hg.mozilla.org/releases/mozilla-beta/rev/e845a10035f2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 ID:20130416200523

Add request to track
status-firefox21: unaffected → ---
status-firefox22: unaffected → ---
tracking-firefox21: - → ?
tracking-firefox22: - → ?
tracking-firefox23: --- → ?
Brendan, can you put together a try build with your proposed fix so Alice0775 can try to reproduce with it and see if you've got the right fix?
status-firefox21: --- → affected
status-firefox22: --- → affected
status-firefox23: --- → affected
tracking-firefox21: ? → +
tracking-firefox22: ? → +
tracking-firefox23: ? → +
Flags: needinfo?(spammaaja)
Keywords: reproducible
(In reply to Alice0775 White from comment #13)

> I can still reproduce.

Alice, can you state the setup you're using so we can have more visibility into why this might not repro in a VM?

Comment 16

5 years ago
(In reply to lsblakk@mozilla.com from comment #15)
> (In reply to Alice0775 White from comment #13)
> 
> > I can still reproduce.
> 
> Alice, can you state the setup you're using so we can have more visibility
> into why this might not repro in a VM?


1. Windows7 64pit SP1 Home Premium
2. Setup local printer (Ex. Microsoft XPS Document Writer)
3. Install Nightly23.0a1 from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
4. Start Nightly with clean profile (regardless of HWA on/off)
5. Open the pdf http://p4_e10.s3.amazonaws.com/files/225/E10_soveltuvuus_henkiloautoihin_27_05_2011.pdf
6. Goto Print Preview and Click Print
7. Select the printer, Click OK.
8. Type filename in file picker dialog and Click SAVE
9. Wait

Actual Results:
"An error occurred while printing."

PS
I can also reproduce in VMware player WindowsXP SP3 Professional (host OS Windows7 64pit SP1 Home Premium).
(Assignee)

Comment 17

5 years ago
(In reply to lsblakk@mozilla.com from comment #14)
> Brendan, can you put together a try build with your proposed fix so
> Alice0775 can try to reproduce with it and see if you've got the right fix?

Still building, but here it is....
https://tbpl.mozilla.org/?tree=Try&rev=26118f5db712

Comment 18

5 years ago
(In reply to Brendan Dahl from comment #17)
> (In reply to lsblakk@mozilla.com from comment #14)
> > Brendan, can you put together a try build with your proposed fix so
> > Alice0775 can try to reproduce with it and see if you've got the right fix?
> 
> Still building, but here it is....
> https://tbpl.mozilla.org/?tree=Try&rev=26118f5db712

The try server build works fine.
http://hg.mozilla.org/try/rev/26118f5db712
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130425 Firefox/23.0 ID:20130425111346
(Assignee)

Comment 19

5 years ago
(In reply to Alice0775 White from comment #18)
> The try server build works fine.
> http://hg.mozilla.org/try/rev/26118f5db712
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130425 Firefox/23.0
> ID:20130425111346

I'm still looking into it but there should be a better way to fix this.  Printing from print preview is taking much longer than directly going from print.
(Assignee)

Comment 20

5 years ago
Created attachment 743154 [details] [diff] [review]
patch v1

As discussed on IRC the original window was being set as a background window which meant all the uses of setTimeout on the page were delayed by one second.  One thing I wasn't quite sure on is if we want to set isBackground to false for all documents or only ones with mozPrintCallbacks.

https://tbpl.mozilla.org/?tree=Try&rev=e2566dc3a786
Attachment #743154 - Flags: review?(bugs)
Comment on attachment 743154 [details] [diff] [review]
patch v1

Hmm, is the bug in frontend code. When opening pp, do we not set the
opened tab foreground? I think we should, and do that somewhere in 
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/printing/content/printUtils.js
Attachment #743154 - Flags: review?(bugs) → review-
Oh, hmm, thinking some more...
Considering it is too late to have any speculative fixes for Fx21 at this point, wontfixing this now.It will be great to have a fix for this soon and get it uplifted to Fx22.
status-firefox21: affected → wontfix

Comment 24

5 years ago
Here is another URL that has a very similar problem:

http://iccb.med.harvard.edu/wp-content/uploads/2012/02/ICCB-L-facility-user-billing-form1.pdf

The only difference I saw is that after some delay after the "unknown error" message, a blank page is printed.  The same PDF can be printed without error if Print Preview is not invoked.

In addition, in Print Preview, after the "unknown error" message pops up, the Firefox Print Preview window somehow becomes the only Firefox window, and its "Close" button does not work (although the Windows "X" button at the upper right hand corner still works), leaving no apparent way to get out of it other than to close Firefox entirely (which the Windows "X" button does if you tell the dialog that pops up to go ahead and close multiple tabs, even though no tabs are visible); however, I found out that if you switch between Portrait and Landscape mode (these buttons still work after the "unknown error" message), then the "Close" button works again and lets you get back to your normal Firefox tabs.

The differences from the original post might be due to using Firefox 21 instead of Firefox 20 (just upgraded today, shortly before running into trouble with this URL).
Too late to fix for FF22, and this has been an ongoing issue. No longer needs to be tracked as a critical issue for upcoming releases.
status-firefox22: affected → wontfix
tracking-firefox23: + → -
(Assignee)

Comment 26

5 years ago
Olli,
Did you have any more thoughts on this?  I'd like to fix but I haven't heard any alternative solutions to the above patch.
Flags: needinfo?(bugs)
I still think the "set tab to background" should happen in the front-end code.
And in case we do pp, we should disable it and just have two tabs in the foreground, sort of.

Perhaps dao or gavin have opinion here.
Flags: needinfo?(bugs)
(Assignee)

Comment 28

5 years ago
Created attachment 777408 [details] [diff] [review]
fix v2

Note: depends on bug 886295 being fixed.
Attachment #743154 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Attachment #777408 - Flags: review?(dtownsend+bugmail)
Attachment #777408 - Flags: review?(dtownsend+bugmail) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/4db723a74092
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/4db723a74092
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla26

Updated

5 years ago
Depends on: 907338
You need to log in before you can comment on or make changes to this bug.