1691798 - Firefox 85 fails to print with filter failed error in CUPS (Brother MFC7360N)

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Bill]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Try to print any page from Firefox to a Brother MFC7360N printer through CUPS on a Linux system, using the generic CUPSwrapper provided by Brother

Actual results:

Print job fails with a "filter failed" message.

CUPS error log shows these messages:
D [09/Feb/2021:10:12:28 -0500] [Job 828] Can't use an undefined value as a subroutine reference at /usr/lib/cups/filter/brother_lpdwrapper_BrGenML1 line 565.
D [09/Feb/2021:10:12:28 -0500] [Job 828] PID 17699 (/usr/lib/cups/filter/brother_lpdwrapper_BrGenML1) stopped with status 255 (Unknown error 155)

Analysis of the lpdwrapper perl script found that the failure is due to a missing unit (e.g. mm, in, pt) at the end of a custom pagesize. Firefox has passed the page size (US letter) as this:

D [09/Feb/2021:10:12:28 -0500] [Job 828] argv[5]="PageSize=Custom.612.00x792.00 Collate Duplex=None job-uuid=urn:uuid:b1ae6b38-c125-3711-62c0-2aa4db7fac70 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1612883548 time-at-processing=1612883548"

The 612x792 size is the US letter size in points and the wrapper script was expecting a 'pt' at the end. When specifying a custom page size, Firefox should put the units abbreviation at the end.

As a workaround, the problem can be patched by making the lpdwrapper perl script default to 'pt' on custom page sizes.

The failure was consistent on all pages tried, and for all paper sizes tested.

Expected results:

Page should have printed normally. Printing from Firefox used to work on my system, but the failure started sometime around Firefox 84.0.2, and continues with 85.0.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Toolkit::Printing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Jan Broendum Johansson]

Hi Bill, I had printing problems in 75.0 but not in 85.0.1, is your Firefox 85.0 or 85.0.1?

I described my problem here(which mozilla archived without even trying to solve the problem)
https://support.mozilla.org/en-US/questions/1285212#answer-1309224

Did you fix your problem?

I have read numerous threads now and not only on this site, where this bug seem to jump between versions and OS, so it would be nice if mozilla could get this one fixed. Maybe on my next update the problem will be back, who knows:(

Jan

Comment 3

[Bill]

Hi Jan,

I first saw the problem in Firefox 84.0.2, and when it persisted in 85.0 I filed the report. It's likely that the problem appeared when the Firefox printing subsystem started mapping all page sizes (letter, legal, A4, etc.) to a custom size in points. It's not clear to me why this change was made, or even whether it was intentional, as the list of supported page sizes comes from the printer definition and so should be handled correctly by all printers. Using a custom page size means that seldom used and probably poorly tested parts of the printer driver layer are now being used for every printing job. I'm hoping that someone familiar with the Firefox printing kit will weigh in with a rationale for the custom page size switch. FWIW, Chrome passes the page size as letter, A4, etc.

I couldn't find a clear specification of the custom page size option in the CUPS documentation, but the docs for the lp command include an example with a custom page size in points without a unit spec, implying that dimensions in points are the intended default. If this is the case, the current behavior of Firefox is not actually incorrect, only misguided.

I fixed the problem in my system with a patch to the cupswrapper perl script supplied by Brother. I'm planning to send the changes to Brother (if they're interested), and could post a patch here if anyone needs it.

Bill

Comment 4

[Tom S [:evilpie]]

Seems to me that we are using a pretty nroaml GTK API for this in nsPrintSettingsGTK::SetPaperId? https://searchfox.org/mozilla-central/rev/8432d4fe31245ae9121231d7c0335aaa342675d2/widget/gtk/nsPrintSettingsGTK.cpp#411. Maybe we should try to use built-in paper-sizes that match in size.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Yeah, we're using GTK for this, so this is quite odd. Might be an upstream gtk bug but we could probably work around it... Is there any chance you could use mozregression to see when this regressed? You should be able to do this with something like mozregression --good 83 --bad 84. If not let me know and I can try to figure out how to figure out if a job is good or bad without the relevant hardware.

Comment 6

[Bill]

I'll take a look at mozregression to see if I can use it here ..

However, it may possible to check for this problem on any system with CUPS, without having the specific failing printer installed. It looks like the CUPS error log is showing the parameters being passed from the application layer to whatever printer is selected. Try setting Loglevel to debug in the CUPS config file, then print a page. Search the error log for argv[5 and if it shows a custom page size in the parameter list, that's the condition that triggered this failure.

I do want to note that the custom page size being passed does change if you select a different paper size, so the printing kit is not ignoring the user's selection.

Comment 7

[Bill]

Hi Emilio,

I downloaded mozregression and tested some builds .. seems like a very useful tool!

The results were a bit unexpected but hopefully useful .. seven builds tested between 2020-09-26 and 2020-11-02 all emitted custom page sizes and would have triggered the failure. Three builds tested from 9/7, 9/21, and 9/24 were not able to put up the print review dialog -- it just hung with a blank page -- so no further testing was possible.

So based on this I would guess that there was a major overhaul of the printing toolkit in progress during September 2020, and when the smoke cleared the page size had switched to custom. Since most printers handle the custom size correctly, nobody reported any problems until quite a while later. (I don't need to print from Firefox all that often.)

Bill

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Thanks for the comments! There are some tricks that could be pulled up to bisect around those dates, I suspect flipping print.tab_modal.enabled could come up with a print dialog. Let me try to figure out what caused this using the cups log.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Ok, so I finally took some time to do this. Bisected down to:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6de217c870da1bca0141ab610eb46b9aec91b840&tochange=b74ab1682deaf69e9d0eac0fb9c29e7e7a5a7a0b

For my own future reference, the bisection method has basically been looking at the spool files in /var/spool/cups like this, since journalct didn't show all the job details like your logs:

$ while true; do strings c<job-id> | rg -C 1 PageSize; if [ $? -eq 0 ]; then break; fi; sleep 1; done

So this looks like a regression from bug 1660527.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

So we have a pre-existing workaround which is somehow not actually working.

This is all sad, this comes from bug 414314, one would've hoped print driver bugs would have been fixed by now :-)

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1691798 - Prefer finding by ipp name when canonicalizing paper size in gtk. r=AlaskanEmily,jfkthame

Due to a rounding issue in gtk_paper_size_new1, we were ending up with
a custom page size regardless, which causes issues with some printers.

Instead, use the gtk_paper_size_new_from_ipp, which is available in all
gtk versions we support, works nicely for our use case, has some
tolerance for minor floating point rounding issues, and should also get
a nicer codepath than the custom page size.

Before bug 1660527 we were using the printer settings, which had a paper
size created from gtk itself without parsing the ipp header, so we were
getting the happy path.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

This was all supposed to work after all, but turns out a rounding issue in GTK caused it not to work. Sadness.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1590390fe40771fdde6a5b6233a22c3444631769 should have a build in about an hour or so (click on the "B", then go to the "Artifacts" tab, then you can download a tarball with a Firefox binary). Could you check that build works for you?

Also, if you could contact the support for your printer pointing to this bug it'd be greatly appreciated! That way they can hopefully fix it in the future :)

Thanks!

Comment 13

[Bill]

Hi Emilio,

Excellent, glad to see you were able to track it down so quickly! Once Firefox reverts to using native page sizes, this bug will become mostly moot -- but before closing it would be nice if someone familiar with the CUPS docs could confirm that the dimensions in custom page sizes are supposed to default to points when no units are given.

Then when I send the patch to Brother, I can reference this bug and they will have some incentive to patch their script.

It sounds like it would be helpful if a regression test for printer paper selection could be added to your test suite -- maybe something to run through all the paper sizes and verify that each size makes it to the CUPS layer?

Thanks for your work!

Bill

Comment 14

[Emilio Cobos Álvarez (:emilio)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1590390fe40771fdde6a5b6233a22c3444631769 should have a build in about an hour or so (click on the "B", then go to the "Artifacts" tab, then you can download a tarball with a Firefox binary). Could you check that build works for you?

Aand... the build from automation failed of course. Seems I was wrong, I thought we required GTK 3.16 but we require 3.14, so I need to add a version check etc... Will be right back with another build.

(In reply to Bill from comment #13)

It sounds like it would be helpful if a regression test for printer paper selection could be added to your test suite -- maybe something to run through all the paper sizes and verify that each size makes it to the CUPS layer?

Yeah, unfortunately I can't think of an easy way of end-to-end test this... In this case the bug is on GTK, which means that it's worse and I can't even unit test this really, meh :(

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Hopefully good build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d326496908bb7cb89d3b62a40802935f46f8be20

Comment 16

[Bill]

Hi Emilio,

I just tried your new build and printed a page .. worked fine, and the CUPS error_log has this:

D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[0]="BrGenML1"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[1]="862"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[2]="bill"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[3]="Important News"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[4]="1"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[5]="media=na_letter_8.5x11in Collate job-uuid=urn:uuid:ec09b97c-78e2-3b3e-635b-9b944319e458 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1613783328 time-at-processing=1613783328 PageSize=Letter"

So, looks good! With no custom page size it will definitely avoid the bug in the cupswrapper ..

Bill

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ef18a39a5f21
Prefer finding by ipp name when canonicalizing paper size in gtk. r=AlaskanEmily

Comment 18

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/ef18a39a5f21

Comment 19

[Bill]

Attachment: Patch for BrGenML1 cupswrapper

I sent my cupswrapper patch to Brother via their customer support channel, so hopefully it will get updated at some point.

If anyone with an MFC7360N printer installed as BrGenML1 needs to fix it now, this patch should work:

Comment 20

[Bill]

I sent my cupswrapper patch to Brother via their customer support channel, so hopefully it will get updated at some point.

If anyone with an MFC7360N printer installed as BrGenML1 needs to fix it now, this patch should work:

--- /opt/brother/Printers/BrGenML1/cupswrapper/brother_lpdwrapper_BrGenML1.sav 2014-05-14 00:36:11.000000000 -0400
+++ /opt/brother/Printers/BrGenML1/cupswrapper/brother_lpdwrapper_BrGenML1 2021-02-22 11:39:11.663845167 -0500
@@ -537,36 +537,61 @@

+# Modified 02/2021 to fix breakage with Firefox 85.0, which is passing all
+# page sizes (letter, legal, A4, etc.) as custom sizes in points with no
+# units. See Bugzilla bug #1691798 for details.
+#
+# 1. Custom page sizes should default to dimensions in points when no units
+# are specified. Although not well documented, the CUPS docs for the 'lp'
+# command show an example with a custom page size in points without units.
+# 2. Make parsing case-insensitive.
+# 3. Handle edge case of trailing decimal point.
+# 4. Report errors to CUPS log for invalid patterns or unexpected units.
+#
sub check_custom_paper {
my $x = 0;
my $y = 0;

• my $unitfunc;

• my $unit = '';

• my $ssize = '';

  (my $PPD , my $lpr_options_ref) = @_;

• if ( $lpr_options_ref->{'-pt'} eq "CUSTOM0" ){

• my $lpr_opt = $lpr_options_ref->{'-pt'};
• if ( $lpr_opt eq "CUSTOM0" ){

• foreach (keys %units){

•   if ( $ppdcust =~ /[0-9]$_$/) {
  

•   logprint( 2 ,   "HIT $_\n");
  

•   $unit = $_;
  

•   $unitfunc = $units{$_};
  

•   }
  

• Verify custom spec and extract fields ..

• if ( $ppdcust !~ /^Custom.([0-9.]+)x([0-9.]+)(\D*)$/i ) {

•   # custom pagesize doesn't match expected pattern ..
  

•   logprint( 0 ,  "Invalid custom pagesize '$ppdcust'\n");
  

•   # log to STDERR so it's visible in the CUPS error log
  

•   print STDERR  "lpdwrapper invalid custom pagesize=$ppdcust\n";
  

•   return ("{Undefined}" , "{Undefined}");
  

  }

• $ssize = $ppdcust;
• $ssize =~ s/^Custom.//g;
• $ssize =~ s/$unit$//g;
• my @psiz = split (/x/,$ssize);
• ($x , $y) = &$unitfunc ( $psiz[0] ,$psiz[1]);

• save extracted fields

• my $width = $1;
• my $height = $2;
• my $unit = lc($3);

• select the appropriate unit conversion function, with points as default

• my $unitfunc = $units{'pt'};
• if ( defined(%units{$unit}) ) {

•   # Valid units found .. use associated function
  

•   $unitfunc = $units{$unit};
  

•   logprint( 2 ,   "HIT $unit\n");
  

• }
• elsif ($unit eq '') {

•   # No units specified .. log as default
  

•   logprint( 2 ,   "DEFAULT pt\n");
  

• }
• else {

•   # Unexpected units .. complain but default to points
  

•   logprint( 0 ,   "WARNING: pagesize '$ppdcust' has unexpected units, using pt\n");
  

•   # log to STDERR so it's visible in the CUPS error log
  

•   print STDERR  "lpdwrapper pagesize=$ppdcust has unexpected units, using pt\n";
  

• }
• ($x , $y) = &$unitfunc ( $width , $height);
  return ($x , $y);
  }

• elsif ( $lpr_options_ref->{'-pt'} =~ /CUSTOM[1-9]/ ){

• elsif ( $lpr_opt =~ /CUSTOM[1-9]/ ){

my $tmp = '*PaperDimension '."$lpr_options_ref->{'-pt'}";
my $ssize = `grep \"$tmp\" $PPD`;

@@ -577,6 +602,8 @@
($x , $y) = &pt2dot ( $psiz[0] ,$psiz[1]);
return ($x , $y);
}
+

• Nothing to do for other lpr_opt values ..

  return ("{Undefined}" , "{Undefined}");
  }

Comment 21

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

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 22

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9204326 [details]
Bug 1691798 - Prefer finding by ipp name when canonicalizing paper size in gtk. r=AlaskanEmily,jfkthame

Beta/Release Uplift Approval Request

• User impact if declined: Some printers will not work on Linux.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: (Needs specific hardware, but see comment 0)
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): I'd say it's a relatively low-risk change. We try a bit harder to find a paper that GTK understands.
• String changes made/needed: none

Comment 23

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9204326 [details]
Bug 1691798 - Prefer finding by ipp name when canonicalizing paper size in gtk. r=AlaskanEmily,jfkthame

Approved for 87.0b3. Would be great if the reporter can verify that this is fixed for them after it ships to the Beta channel tomorrow.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2a069623700d

Comment 25

[Bill]

I downloaded Firefox 87.0b3 and tested by printing three pages with different page sizes. The pages printed as expected and a check of the CUPS error log showed that the page sizes matched the requested sizes (Letter, A4, and A5):

D [26/Feb/2021:07:56:51 -0500] [Job 872] argv[3]="Firefox"
D [26/Feb/2021:07:56:51 -0500] [Job 872] argv[4]="1"
D [26/Feb/2021:07:56:51 -0500] [Job 872] argv[5]="media=na_letter_8.5x11in Collate Duplex=None job-uuid=urn:uuid:00d32aec-918c-34c1-4de7-6bdd9b793d72 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1614344211 time-at-processing=1614344211 PageSize=Letter"

D [26/Feb/2021:07:58:58 -0500] [Job 873] argv[3]="Firefox"
D [26/Feb/2021:07:58:58 -0500] [Job 873] argv[4]="1"
D [26/Feb/2021:07:58:58 -0500] [Job 873] argv[5]="media=iso_a4_210x297mm Collate Duplex=None job-uuid=urn:uuid:5673122e-a107-3c4d-6d6b-d157318c3ab6 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1614344338 time-at-processing=1614344338 PageSize=A4"

D [26/Feb/2021:08:00:54 -0500] [Job 874] argv[3]="Firefox"
D [26/Feb/2021:08:00:54 -0500] [Job 874] argv[4]="1"
D [26/Feb/2021:08:00:54 -0500] [Job 874] argv[5]="media=iso_a5_148x210mm Collate Duplex=None job-uuid=urn:uuid:03a5da63-49a9-3169-7277-24ec7397013c job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1614344454 time-at-processing=1614344454 PageSize=A5"

Previously all page sizes had been mapped to a custom size, so the bug has been fixed in 87.0b3.

Thanks for the quick resolution of this problem!

Comment 26

[Jan Broendum Johansson]

Yesterday, my system got updated to 86.0 and then suddenly I couldn't print again, also now I were looking at the new FF print interface.

85.0.1 worked, 86.0 does not, that 87.0b.3 works is nice - but don't guys think that you should send out a patch to solve it now, instead of people having to wait for 87 which comes out on march 23?

And that finding the cause of this would be a good idea, so that it doesn't happen again and again, and so on in every second release - it started for me with 75.

For now: I figured out a work around for those who don't want an developer beta version installed, and will wait for 87 to come out march 23:

click on "Print..." Ignore the new print interface of FF and click on "Print using system dialog..." change the papersize to first A5 and then back to A4 the printer now prints as it should.

Again: This do NOT work with Firefox new build-in printer settings.

Jan
I'm have been a loyal user since Netscape, at that time I worked support for many companies that bought IBM, Compaq, HP and Packard Bell computers and various printers, for their offices and Home PC users.

I quit Windows for good about 6 years ago, and went on different distro of Linux, until i found the one I'm using for the past 6 years as my permanent driver, when you guys make changes like this and break things, it were hard enough in windows(which most developers still seem prioritize over linux), and makes it even harder in linux. Maybe don't try to be the first to come out with new stuff, but test it first and then send out a stable solution. Thank you for all the years past:)

Comment 27

[Bill]

Hi Jan,

If you're seeing on-again, off-again printing with recent Firefox builds, the problem is likely different from the custom pagesize issue here. To track it down further, I'd suggest turning on CUPS debugging by setting Loglevel to debug in the CUPS config file. Then try printing a page using a failing Firefox build, and inspect the CUPS error log for signs of problems with that print job.

If nothing obvious pops out, try printing the same page with the same settings from a Firefox build that works, and look for differences in the CUPS error log between the two jobs. If you can pinpoint the cause in the error logs, there's a much better chance that the problem can be fixed, either in Firefox or by tweaking your printer driver setup.

On my system I keep CUPS debugging turned on (with a 1M file limit) so that it's easier to track down printer problems.

Comment 28

[Emilio Cobos Álvarez (:emilio)]

Yeah, this change isn't in Firefox 86. If you can reproduce on Beta 87 or Nightly, please file a new bug and ni? me and I'd be happy to poke at it. Thanks!

Comment 29

[Jan Broendum Johansson]

Well, I disagree - I'm not an expert in this, but if I change page size then print works, so must have something to do with the bug, right?

click on "Print..." Ignore the new print interface of FF and click on "Print using system dialog..." change the papersize to first A5 and then back to A4 the printer now prints as it should.

I have no idea on how to turn on debug in loglevel or where to find the CUPS config file, and even how to see the log.

I quit windows because I had enough of MS's BS(after working with their products as supporter and IT consultant for over 35 years), and tried many different kind of OS's before landing on the one I use now, which a slightly modified Xubuntu 16.04 and when 20.04 is finished I will go on that one - might take a while since the author is busy with something else:)

In the meantime it would be nice to be able to print from FF.

Though I may not know how to do something, doesn't mean I'm not willing to learn:)

Jan

Comment 30

[Emilio Cobos Álvarez (:emilio)]

Please do file a separate bug if using a nightly build doesn't work, and we can debug it there. We can mark the bug as "See also" or such to indicate that this bug might be related.

Comment 31

[Bill]

Hi Jan,

If you enter localhost:631/admin as the URL in your browser, it should take you to the CUPS admin page. On the right side there are buttons to edit the config file and to view the error log. Once debugging is turned on, if a print job fails there will likely be some messages in the error log as to the the cause of the failure.

Since you can make the print jobs succeed or fail by fiddling with paper sizes, you should be able to capture some specific error messages so the bug can be tracked and fixed.

Good luck with the bug hunting!

Bill

Comment 32

[Jan Broendum Johansson]

Hi Bill, Content of the config file - I can't see where to turn on logging:
LogLevel debug
PageLogFormat
MaxLogSize 0

Allow remote access

Port 631
Listen /var/run/cups/cups.sock
Browsing On
BrowseLocalProtocols dnssd
DefaultAuthType Basic
WebInterface Yes
<Location />

Allow remote access...

Order allow,deny
Allow all
</Location>
<Location /admin>
</Location>
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
</Location>
<Location /admin/log>
AuthType Default
Require user @SYSTEM
Order allow,deny
Order allow,deny
Allow all
Order allow,deny
Allow all
</Location>
<Policy default>
JobPrivateAccess default
JobPrivateValues default
SubscriptionPrivateAccess default
SubscriptionPrivateValues default
<Limit Create-Job Print-Job Print-URI Validate-Job>
Order deny,allow
</Limit>
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit CUPS-Authenticate-Job>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit All>
Order deny,allow
</Limit>
</Policy>
<Policy authenticated>
JobPrivateAccess default
JobPrivateValues default
SubscriptionPrivateAccess default
SubscriptionPrivateValues default
<Limit Create-Job Print-Job Print-URI Validate-Job>
AuthType Default
Order deny,allow
</Limit>
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit Cancel-Job CUPS-Authenticate-Job>
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit All>
Order deny,allow
</Limit>
</Policy>

Comment 33

[Jan Broendum Johansson]

In the admin page this one do have a checkmark, is that what you meant?

Save debugging information for troubleshooting

Comment 34

[Bill]

Hi Jan,

The first line LogLevel debug is what you need -- debugging is already turned on. If you check the Error log now after a failing job, there should be some good clues as to what went wrong. The error log is usually pretty verbose though, so it may take a while to locate the messages for a particular job.

The checkmark may be what turned on the debugging, but in any event it's on.

Bill

Comment 35

[Jan Broendum Johansson]

Printing via FF own new print option, error log attached.

Comment 36

[Jan Broendum Johansson]

That didn't work, I got an error when trying to attach text.
i have uploaded everything to my dropbox, screenshot and log files here https://www.dropbox.com/sh/4sl94pledbodkvy/AACv9zIt3OrUFJEjikwfNXjba?dl=0

Comment 37

[Bill]

Hi Jan,

The CUPS error log is very noisy, so you'll need to dig into it to find the relevant problem. The screeenshot showed that Job 233 failed, and if you search the error log for 233 you find this:

800] cupsdMarkDirty(---J-)
D [18/Mar/2021:10:51:32 +0800] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [18/Mar/2021:10:51:32 +0800] [Job 233] PID 12182 (/usr/lib/cups/filter/rastertocanonij) stopped with status 255 (Unknown error 155)
D [18/Mar/2021:10:51:32 +0800] [Job 233] PID 12180 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
D [18/Mar/2021:10:51:32 +0800] [Job 233] Color Manager: Calibration Mode/Off

So the problem apparently occurred in the filter rastertocanonij. The next step would be to see if that filter left around some tmp files, or if it has a debugging mode that can be turned on. There may be some additional messages there that would help diagnose the problem further.

Anyway, you're much closer to finding the problem :-)

Comment 38

[Jan Broendum Johansson]

Hi Bill, after updating to FF 87.0 the problem is gone, just hope it will not re-occur.

Thank you for all you patience helping me look into this, at last it would seem it indeed were a FF problem, as I have not done anything else than updating FF.

with kind regards and if you are ever finding yourself in Puerto Galera, Oriental Mindoro, 5203 Philippines, then look me up. I live above and on the back of Iglesia ni christo. And I buy you a steak:)

Jan