1468465 - 'An error occured while printing' on any documents except for internal Firefox ressource pages

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[klk745]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180605201706

Steps to reproduce:

1. Open https://bugzilla.mozilla.org/, hit Ctrl-P and confirm to print.
2. Open a local txt file with 'test' as content, hit Ctrl-P and confirm to print.
3. Open about:support, hit Ctrl-P and confirm to print.


Actual results:

After step 1 or 2: a window with the message "An unknown error occured while printing" comes up (preceded by a progressbar labeled 'null' for a blink of an eye). The printer outputs a blank page.

After step 3: Printing works fine.


Expected results:

Printing from resources other than about:xxxx should work fine as it did before upgrade from Firefox ESR 52 to 60.

Comment 1

[klk745]

Additional informations:
Changing security.sandbox.content.level from 5 to 0 followed by a Firefox restart makes no difference.
A Temp-{<guid>} folder in C:\Users\<username>\AppData\LocalLow\Mozilla is successfully being created by Firefox.

Comment 2

[klk745]

I was able to fix the problem by disabling the hardware acceleration in about:preferences (restart required).
This course can't be a permanent solution, because the missing hardware acceleration can be felt while browsing.

I'm on Intel Iris Pro Graphics 6200 with the latest drivers offered thru Windows.
Since this is a typical business/office environment this could cause a lot of hassle when the ESR upgrade to 60 is offered after 52 becomes EOL. It's also interestinng that I didn't have this problem in ESR 52 with hardware acceleration enabled.

So it might be worth considering to disable hardware support just for printing anyway in the next point release, since I don't see the benefit if a page prints 100ms faster or slower vs. doesn't print at all respectively printing out blank sheets of paper.

Comment 3

[klk745]

Some additional information about my environment, that might be related.
If you need further infos, let me know.

Direct2D	true
DirectWrite	false (6.2.9200.22164)

WebGL is currently disabled. [for both 1 & 2]

Driver version:	20.19.15.4835
Driver date:	10-16-2017

WEBRENDER	opt-in by default: WebRender is an opt-in feature
unavailable by runtime: Build doesn't include WebRender
OMTP	broken by runtime: OMTP is not supported when using cairo
ADVANCED_LAYERS	available by user: Enabled for Windows 7 via user-preference
NO_CONSTANT_BUFFER_OFFSETTING	Unsupported by driver

Comment 4

[klk745]

This bug seems to be caused by the same issue in bug report #1451507:
https://bugzilla.mozilla.org/show_bug.cgi?id=1451507

Comment 5

[jws]

@klk745: I suggest you run mozregression (https://mozilla.github.io/mozregression/quickstart.html) to see if you get the same result I do, i.e. to verify that your bug is the same as mine (#1451507).

Comment 6

[Bob Owen (:bobowen)]

Attachments from bug 1451507:
Failed printing attempt for Page 1 of https://www.heise.de/newsticker/:
https://bugzilla.mozilla.org/attachment.cgi?id=8986014
Successful printing attempt with HW acceleration disabled:
https://bugzilla.mozilla.org/attachment.cgi?id=8986018

(In reply to klk745 from bug 1451507 comment #22)
> Created attachment 8986014 [details]
> Printing attempt for Page 1 of https://www.heise.de/newsticker/

As far as I can tell for your problem, the playback of draw commands in the parent is probably failing here:
https://searchfox.org/mozilla-central/rev/f822a0b61631cbb38901569e69b4967176314aa8/layout/printing/ipc/RemotePrintJobParent.cpp#145

It's not clear to me why having acceleration enabled should cause issues for printing, my guess is that the data we are getting from Direct2D are incompatible with the cairo playback for some reason.

In addition to the regression range suggested in comment 5, would you mind trying a single debug build with the Mozregression-gui as well:
* File->"Run a single build"
* Select "Build Type:" debug, then Next
* Next on the "Profile Selection" panel
* It should automatically select a recent build date I think, if not select one from a few days ago and then Finish.

It will be pretty slow to start and run, assuming the print fails can you upload a copy of the log, thanks.

Comment 7

[klk745]

Will the debug build in mozregression use my regular FF profile (and potentially screw it up) or will it create a new one isolated from it?

Comment 8

[Bob Owen (:bobowen)]

(In reply to klk745 from comment #7)
> Will the debug build in mozregression use my regular FF profile (and
> potentially screw it up) or will it create a new one isolated from it?

By default, it creates a new one in %TEMP%.
This is one of the nice things about using mozregression for these sorts of tests.
You can select a specific profile if required and even then I think the default option is to clone that profile to a temporary one.
I'm not sure though, so I'd just let it create a new one and stay away from your regular one.

Comment 9

[klk745]

OK, installed it and it offered me a 62.x debug nightly build, which printed without a problem (HW acceleration was on by default).
Pardon my ignorance, but how can I force mozregression-gui to offer me the current 60.0.2 ESR as debug build?

Comment 10

[klk745]

What confuses me the most is that I can print about:support, about:performance, about:credits, about:memory and so on without any problems. Is there probably some sort of switch inside the code which handles those pages differently?

BTW: I've also disabled all my addons followed by a restart to see if that makes a difference, but it's the same behaviour.

Comment 11

[klk745]

Attachment: config_values_gfx_print.gif

Comment 12

[klk745]

Attachment: about_support_graphics.gif

Comment 13

[klk745]

I've added two attachments with the graphic values from about:support and the config values for gfx.* and print.*.

Comment 14

[Bob Owen (:bobowen)]

(In reply to klk745 from comment #9)
> OK, installed it and it offered me a 62.x debug nightly build, which printed
> without a problem (HW acceleration was on by default).
> Pardon my ignorance, but how can I force mozregression-gui to offer me the
> current 60.0.2 ESR as debug build?

In the last panel, you can change it to select by release instead of date and select 60.
That will get you fairly close to the current release.

Also, it's possible that using a clean profile has fixed things.
You could test this on your standard install by running Firefox like this:
  firefox.exe -no-remote -P

This opens the profile manager and allows you to create a new profile.
(The -no-remote allows you to run two versions of Firefox, in case one is already running.)

(In reply to klk745 from comment #10)
> What confuses me the most is that I can print about:support,
> about:performance, about:credits, about:memory and so on without any
> problems. Is there probably some sort of switch inside the code which
> handles those pages differently?
> 
> BTW: I've also disabled all my addons followed by a restart to see if that
> makes a difference, but it's the same behaviour.

This is probably beause these pages run in the main process and so go through different code when printing.

Comment 15

[Timea Cernea [:tbabos][inactive]]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Reproduced the issue on the latest Nightly 64.0a1 (20180925220052) on Mac OS 10.13. and Windows 10 x64.
Please note that in my case, the error appears after Ctrl + P however, the page can still be printed.
I used the following 2 documents for printing: 
https://drive.google.com/file/d/0BzOV3ybvBASXcTFiVngyRmx3UkE/view
https://drive.google.com/file/d/0BzOV3ybvBASXX3EyYzNMWllqVG8/view

Here is the actual behavior: https://streamable.com/9hewz

Comment 16

[[:philipp]]

testing the docs from comment #15 reproduces the issue for me as far back as in firefox 56.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 18

[Wayne Mery (:wsmwk)]

Does this still reproduce for you?

Comment 19

[klk745]

No - made the switch to Linux with a fresh Firefox installation 4 years ago, can't reproduce it anymore and hasn't happened for me on Linux.
I think you can close the bug.

Comment 20

[Jonathan Watt [:jwatt]]

Thanks for taking the time to reply.