Closed Bug 1659928 Opened 4 years ago Closed 4 years ago

Print Preview and printing shows as empty or very tiny page for all printers except "Save as PDF"

Categories

(Core :: Printing: Setup, defect, P2)

Product:
Core
Component:
Printing: Setup
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox80 --- unaffected
firefox81 + wontfix
firefox82 + fixed
firefox83 + fixed

People

(Reporter: whimboo, Assigned: jwatt)

References

Details

(Whiteboard: [print2020_v82])

Attachments

(3 files)

Screenshot 2020-08-19 at 10.11.54.png
520.93 KB, image/png
Details
all lines from a pref.js which contain the string "print"
5.82 KB, text/plain
Details
prefs.js after a print on ubuntu 16.04
16.83 KB, application/x-javascript
Details

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0 ID:20200816214203

Opening the new print preview and having a printer other than Save to PDF selected, will only render a tiny and empty preview document. See the attached screenshot.

I feel like we've got some changes that might fix that, but I'd also be interested in the value of your print.print_paper_height pref…

Severity: -- → S2
Priority: -- → P1
Whiteboard: [print2020_v81]

It's 297.00 which corresponds to A4 format.

Does it affect anything if you change it to 11? (I don't think that's a good answer, I'm just trying to see how it affects things…)

When I change the preference it only affects the output for Save to PDF, but not for real printers.

I suppose 297.00 in millimeters, and 11 is in inches. I am almost 100% sure print.print_paper_size_unit value is 1 (which is the unit is millimeters) in Henrik's environment.

Yes, that's correct.

Daniel, does this seem like it could be a print preview bug?

Flags: needinfo?(dholbert)

(In reply to Mark Striemer [:mstriemer] from comment #7)

Daniel, does this seem like it could be a print preview bug?

Given that it works for some printers (well, for the "Save to PDF" printer), I would bet this is a bug earlier in the pipeline than the Print Preview code; i.e. a bug in determining the paper size in the print settings, or something.

Henrik:

  • can you reproduce with a fresh profile?
  • What happens when you actually print to one of these printers where the preview is a weird-tiny-rect? (hopefully you've got one of them locally available)
Flags: needinfo?(dholbert) → needinfo?(hskupin)

Strange. I deleted a lot of preferences for printers which don't exist anymore. And then after opening and closing print preview I noticed that the page height and width is not in sync anymore with the paper size unit. Updating it to the correct values it works fine:

print.printer_HP_LaserJet_MFP_M28w.print_paper_height	 11.69	
print.printer_HP_LaserJet_MFP_M28w.print_paper_name	iso-a4
print.printer_HP_LaserJet_MFP_M28w.print_paper_size_unit	1
print.printer_HP_LaserJet_MFP_M28w.print_paper_width	  8.26
Flags: needinfo?(hskupin)

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #9)

after opening and closing print preview I noticed that the page height and width is not in sync anymore with the paper size unit.

I'm not sure what this means - can you clarify what you noticed regarding out-of-sync units here?

Also: do you happen to still have the incorrect/brokenness-inducing pref values? And (if so) does the problem still happen if you restore those pref values?

If there's a population of users out there who have similarly-broken print settings for some reason, it would be useful to be able to do some further investigation into what's broken & what we can do about it...

Flags: needinfo?(hskupin)

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #9)

Strange. I deleted a lot of preferences for printers which don't exist anymore.

I suppose, disabe print.tab_modal.enabled and open the old print preview and change the paper size, then the preference will be re-appear. I am super unfamiliar how we handle those paper settings in the new print preview UI, so no idea what's going on there.

CCing Erik who knows about paper settings better than me.

(In reply to Daniel Holbert [:dholbert] from comment #10)

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #9)

after opening and closing print preview I noticed that the page height and width is not in sync anymore with the paper size unit.

I'm not sure what this means - can you clarify what you noticed regarding out-of-sync units here?

From the values above size unit is 1 which means mm. But height is listed as 11 and as such would mean 11mm.

Also: do you happen to still have the incorrect/brokenness-inducing pref values? And (if so) does the problem still happen if you restore those pref values?

When I remove the custom values in about:config the print preview is rendered correctly afterward. Probably height and width aren't getting added again. Even when I print with the system dialog these preferences don't exist anymore afterward?

(In reply to Daniel Holbert [:dholbert] from comment #8)

  • can you reproduce with a fresh profile?

No.

  • What happens when you actually print to one of these printers where the preview is a weird-tiny-rect? (hopefully you've got one of them locally available)

Even with the print preview broken the actual printed document looks fine.

Flags: needinfo?(hskupin)

Sooo, since we don't know how the values got messed up in the first place, I'm not sure there's much we can do for 81. (Other than being sure to mention it in the notes to SUMO!)

(I'm changing it to a P2, for the more general work of ensuring that configs we load have reasonable values, and attempting to fix them if they don't.)

Priority: P1 → P2
Whiteboard: [print2020_v81] → [print2020_v82]
Priority: P2 → P3
Summary: Print Preview document shows as empty tiny page for all printers except "Save as PDF" → Sanity-check page size settings on load.

Please note that I have the same problem now with a different profile and Firefox 81 beta, but with the old (system) print dialog! Printing including save to PDF creates a very tiny page. The only workaround is to save the PDF and to print via another tool.

[Tracking Requested - why for this release]:
This is actually more problematic as I first thought. As mentioned in my former comment this happens across profiles, and a separate test by removing all the printer preferences doesn't help at all. Printing is not just not possible for me because whatever I try it's just an empty page.

Note that I can not select Save as PDF when printing Firefox 81 because the OS dialog seems to handle that via the selected printer.

We may not be able to block the 81 release on that but we should be aware that a follow-up fix might be necessary. Maybe this will hit folks with a metric locale?

I'm resetting the changed summary to make this bug easier to discover.

status-firefox81: --- → affected
status-firefox82: --- → affected
tracking-firefox81: --- → ?
Flags: needinfo?(dholbert)
Flags: needinfo?(bwinton)
Summary: Sanity-check page size settings on load. → Print Preview and printing shows as empty or very tiny page for all printers except "Save as PDF"
Priority: P3 → P1

That this wasn't a transient thing is worrying. I'm not sure there's much the frontend can do about this though. Moving to Platform for now.

Component: Printing → Printing: Setup
Product: Toolkit → Core

Agreed that this sounds worrying. Given that we're shipping 81.0 tomorrow, I'm wondering if at a minimum we need a SUMO article or something for this in case we start seeing more affected users in the wild?

status-firefox80: --- → unaffected
status-firefox83: --- → affected
status-firefox-esr68: --- → unaffected
status-firefox-esr78: --- → unaffected
tracking-firefox81: ? → +
tracking-firefox82: --- → +
tracking-firefox83: --- → +
Flags: needinfo?(jojohnson)

Note that I removed all the prefs manually while running Firefox via about:config. Maybe there is a side-effect? I can try later today to modify prefs.js directly and removing all the printer related preferences before starting Firefox again.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #17)

Agreed that this sounds worrying. Given that we're shipping 81.0 tomorrow, I'm wondering if at a minimum we need a SUMO article or something for this in case we start seeing more affected users in the wild?

Thanks for pinging me on this. I am going to follow up with Joni our SUMO technical writer to see about an article for this.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #17)

Agreed that this sounds worrying. Given that we're shipping 81.0 tomorrow, I'm wondering if [...]

Note that the new tab-modal printing UI (shown in the screenshot) is turned off for Firefox 81.

hskupin, does this bug happen at all if the new tab-modal print UI is turned off? (in print-preview and/or actual printed output)

Flags: needinfo?(dholbert) → needinfo?(hskupin)

(In reply to Daniel Holbert [:dholbert] from comment #20)

hskupin, does this bug happen at all if the new tab-modal print UI is turned off? (in print-preview and/or actual printed output)

Yes, that's what I was describing. It's not turned on, and trying to print results at the moment in empty pages - I even don't see any output right now with the tiny scaling factor.

Let me see if I can find out which profile settings are causing that.

Flags: needinfo?(hskupin)

So when I was saying that I removed the preferences I removed them all for the given real printer, but not those whose look kinda generic or the default settings for new printers? Here is the list of preferences that are causing this trouble:

user_pref("print.print_bgcolor", false);
user_pref("print.print_bgimages", false);
user_pref("print.print_colorspace", "default");
user_pref("print.print_downloadfonts", false);
user_pref("print.print_duplex", 0);
user_pref("print.print_evenpages", true);
user_pref("print.print_footerleft", "");
user_pref("print.print_footerright", "");
user_pref("print.print_headerleft", "");
user_pref("print.print_headerright", "");
user_pref("print.print_in_color", true);
user_pref("print.print_margin_bottom", "0.5");
user_pref("print.print_margin_left", "0.5");
user_pref("print.print_margin_right", "0.5");
user_pref("print.print_margin_top", "0.5");
user_pref("print.print_oddpages", true);
user_pref("print.print_orientation", 0);
user_pref("print.print_page_delay", 50);
user_pref("print.print_paper_data", 0);
user_pref("print.print_paper_height", "297.00");
user_pref("print.print_paper_name", "iso_a4");
user_pref("print.print_paper_size_type", 1);
user_pref("print.print_paper_size_unit", 1);
user_pref("print.print_paper_width", "210.00");
user_pref("print.print_plex_name", "default");
user_pref("print.print_resolution", 301);
user_pref("print.print_resolution_name", "default");
user_pref("print.print_reversed", false);
user_pref("print.print_scaling", "  1.00");
user_pref("print.print_shrink_to_fit", true);
user_pref("print.print_to_file", false);
user_pref("print.print_to_filename", "");
user_pref("print.print_unwriteable_margin_bottom", 24);
user_pref("print.print_unwriteable_margin_left", 19);
user_pref("print.print_unwriteable_margin_right", 19);
user_pref("print.print_unwriteable_margin_top", 24);

When I create a new profile I don't see any of those written to prefs.js.

Reducing those more I come to this list:

user_pref("print.print_paper_height", "297.00");
user_pref("print.print_paper_name", "iso_a4");
user_pref("print.print_paper_size_type", 1);
user_pref("print.print_paper_size_unit", 1);
user_pref("print.print_paper_width", "210.00");
user_pref("print.print_plex_name", "default");
user_pref("print.print_resolution", 301);

For me it's enough to get these added to the pref.js from a new profile to actually break printing.

And yes, testing the same steps with Firefox 80 works and there is the expected print preview with all the content. So the question is when get or got these preferences set, and how many users are actually affected.

After chatting with Jonathan via Matrix it's indeed print.print_paper_size_unit that I have to remove for the default print settings and my actual printer to get printing and print preview working again.

Jonathan mentioned to me that during the early Firefox 81 beta cycle we had the new UI enabled for a while. So I checked when I updated Firefox beta from a 80 to the first 81 beta release:

Firefox 81.0 Beta 2 (20200825191644)Details
Installed on: August 27, 2020, 10:50:13 AMStatus: The Update was successfully installed

Does that qualify an early beta?

To test with an older version of the profile I grabbed a backup from July 23rd via Time Machine. Using the most recent 81 RC (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0 ID:20200917005511) with it, the same problem exists. So I doubt that an 81 early beta is causing that and we still have the problem remaining in 81 for users upgrading from an earlier official release of Firefox.

Flags: needinfo?(jwatt)

Note that the oldest backup that I have is from 29/08/2019 and the prefs.js file also contains print.print_paper_size_unit=1. So I have no idea when that faulty pref has been added.

I can reproduce the blank pages on macOS if I do the following using a build from BEFORE bug 1665904 landed on Sept 20th:

Open Firefox with a new profile, disable the new print UI by setting print.tab-modal.enabled = false. (I don't have a way to repro with the new UI yet.)

Additionally add exactly the following four prefs, paying attention to add them with the specified types:

user_pref("print.print_paper_size_unit", 1);     // number
user_pref("print.print_paper_name", "iso_a4");   // string
user_pref("print.print_paper_width", "210.00");  // string
user_pref("print.print_paper_height", "297.00"); // string

Then print, which opens the system print dialog, and select PDF -> Open in Preview.

We then end up with the value from print.print_paper_size_unit being copied onto the equivalent pref for the printer that was selected by default in the system print dialog (so print.printer_<printer>.print_paper_size_unit) which is the printer the settings come from for the PDF generation, causing the paper settings for that printer to be busted with the incorrect unit.

(In reply to Jonathan Watt [:jwatt] from comment #27)

I can reproduce the blank pages on macOS if I do the following using a build from BEFORE bug 1665904 landed on Sept 20th:

But that only landed on central (82) and should affect what I see for Firefox 81, right?

Depends on: 1666523

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #28)

But that only landed on central (82) and should affect what I see for Firefox 81, right?

It doesn't help us on Release or Beta. That comment was intended for anyone trying to reproduce and debug this on Nightly and thinking the issue doesn't reproduce for them.

Some background: Mozilla can have two sets of printer configuration settings saved to prefs that it may recognize: printer settings saved as "global" prefs without an associated printer name (such as print.print_paper_size_unit) and printer-specific settings saved with the printer name inserted into the pref name (such as print.printer_HP_LaserJet_MFP_M28w.print_paper_size_unit). In code, the distinction is made by the aUsePrinterNamePrefix argument passed to nsIPrintSettingsService.initPrintSettingsFromPrefs and nsIPrintSettingsService.savePrintSettingsToPrefs.

Up until a few days ago, all printer config settings on Linux were saved to prefs without an associated printer name (something that was only just fixed in bug 968753). I had thought that only Linux code reads/writes these supposedly per-printer settings from "global" prefs like this. But it turns out on macOS nsPrintSettingsServiceX::_CreatePrintSettings initializes new nsIPrintObjects using these settings... for some inexplicable reason. This means that if per-printer settings manage to somehow end up in "global" prefs in a user's profile, then on macOS, whenever nsIPrintSettingsService.newPrintSettings/.globalPrintSettings is used we can end up with a settings object that contains a bad .paperSizeUnit. If there are no per-printer prefs for the printer then when we call initPrintSettingsFromPrefs for the printer we're going to use then this setting is not overwritten. Worse yet, we will then save the bad unit into the printer-specific prefs when we save that settings object (details below).

With the old UI (the system print dialog on macOS), I initially hoped that changing the paper size would overwrite any bad .paperSizeUnit value, and act as a "fix" for users that encounter this issue. However, it seems that nsPrintDialogServiceX::Show does not make any effort to update the nsPrintSettingsX members when it sets the new NSPrintInfo on it from the dialog. :-/ Basically [mPrintInfo paperSize] contains the correct size info, but mPaperWidth and mPaperHeight (and mPaperSizeUnit!) are not updated to keep them in sync. That doesn't usually appear to matter because nsPrintSettingsServiceX::SerializeToPrintDataParent serializes from mPrintInfo when passing the settings to the content process, and therefore the settings object that the content process gets and may save to prefs has the corrected width/height, even though the nsPrintSettingsX on the parent side never gets fixed up. However, nsPrintSettingsX::mPaperSizeUnit is passed over to the content process unmodified, and hence we end up saving the wrong unit to the printer specific prefs...

The fact that this code doesn't cause more problems on macOS seems to imply that we never actually have settings objects with 'mm' paper size units normally.

Another observation as to why all four prefs mentioned in comment 27 are necessary to reproduce the issue - that's because nsPrintSettingsService::ReadPrefs reads all or none of those prefs as a group.

As to how common this issue is going to be, I'm expecting it will be relatively uncommon. It seems Henrik copied his profile over from Linux to Mac a couple of years ago, which is presumably how he ended up with the printer settings stored at "global" prefs. Probably relatively few people will be doing that. I was a bit worried that Firefox Sync might copy these printer prefs around, but dholbert dug up info on which prefs we sync and it seems that there are no print. prefs amoungst the prefs that we sync by default.

A couple of thing that currently aren't clear to me:

  • Why this only recently became a problem (another mozregression session required)
  • The exact details of the issue with the new UI (my initial attempts to reproduce the small pages failed)

I'm going to change this to P2 for now given what we know so far, but continue to monitor SUMO, Twitter, etc.

We'll probably partially fix this with the patch for bug 1666473, and then have a follow-up patch for this bug.

Priority: P1 → P2

(I think we have all the info we need now, so removing my needinfo…)

Flags: needinfo?(bwinton)
Flags: needinfo?(jojohnson)

After fixing the bug for Ubuntu 16 LTS that was causing the new print UI to hang, and subsequently never display, there has been at least one report of this issue on that system: (bug 1662946, comment #45).

I just want to make sure it gets noted here and not forgotten.

Lee, interesting that you can still reproduce this on Nightly. Can you go to the page about:support, go to "Profile Folder" line (not "Update Folder") and click "Show in Finder" (or equivalent), open the prefs.js file in that folder, and copy and paste all the lines that contain prefs starting with "print." along with the line containing the pref "print_printer", and attach those lines as an attachment here?

Flags: needinfo?(jwatt) → needinfo?(6dnail)

Lee, please see the question above.

(In reply to Jonathan Watt [:jwatt] from comment #37)

Lee, interesting that you can still reproduce this on Nightly. Can you go to the page about:support, go to "Profile Folder" line (not "Update Folder") and click "Show in Finder" (or equivalent), open the prefs.js file in that folder, and copy and paste all the lines that contain prefs starting with "print." along with the line containing the pref "print_printer", and attach those lines as an attachment here?

Within about:support there is item "Profile Folder". I do find an item "Profile directory", which is probably the same thing. Within that directory I do find a file prefs.js however nowhere in that file (prefs.js) is the character string "print"

Flags: needinfo?(6dnail)

(In reply to Lee McFarland from comment #39)

(In reply to Jonathan Watt [:jwatt] from comment #37)

Lee, interesting that you can still reproduce this on Nightly. Can you go to the page about:support, go to "Profile Folder" line (not "Update Folder") and click "Show in Finder" (or equivalent), open the prefs.js file in that folder, and copy and paste all the lines that contain prefs starting with "print." along with the line containing the pref "print_printer", and attach those lines as an attachment here?

Within about:support there is item "Profile Folder". I do find an item "Profile directory", which is probably the same thing. Within that directory I do find a file prefs.js however nowhere in that file (prefs.js) is the character string "print"

In another firefox profile used with nightly, I find many lines with the string "print". Those lines I am uploading to this bug as file print.txt

Very strange. Firefox always saves print settings to prefs after printing, unless print.save_print_settings is set to false. But if you'd set that, then that pref itself should show up in prefs.js.

What is the current value of print.save_print_settings in about:config? And once you've checked that, can you then set it to true and try printing again, and after you get the small page problem, check in your prefs.js file for that profile to see if the print. prefs are saved then? (You may need to shut Firefox down after the problematic print to get it to write to prefs.js, I guess.

(In reply to Jonathan Watt [:jwatt] from comment #42)

Very strange. Firefox always saves print settings to prefs after printing, unless print.save_print_settings is set to false. But if you'd set that, then that pref itself should show up in prefs.js.

What is the current value of print.save_print_settings is about:config? And once you've checked that, can you then set it to true and try printing again, and after you get the small page problem, check in your prefs.js file for that profile to see if the print. prefs are saved then? (You may need to shut Firefox down after the problematic print to get it to write to prefs.js, I guess.

I've got a secondary firefox nightly profile which is used for testing. It is not used for general browser. My primary firefox nightly might have all kinds of things in it as I use it all the time therefore prior to submitting something to bugzilla I use a relatively 'clean' profile. Until this print issue came up, I'd never printed on the 'blank' profile, which may explain why pref.js had no print information.

I just did a print on the test profile. I used a command line to bring up this 'blank' profile. As a result, some system complaints are written to the command line parent process as they happen. Firefox, like most application typically has a few complaints which I ignore. This time, after bringing up the print function in firefox, a few interesting command line complaints appeared as follows:
(firefox:3053): Gtk-WARNING **: Unknown paper size
(firefox:3053): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

These two lines are repeated more than once. You wouldn't see them if firefox was started from a desktop icon
I also got the following lines on that command line parent process:
(/home/neil/firefoxtest/firefox/firefox-bin:3147): Gtk-CRITICAL **: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3147): Gtk-CRITICAL **: gtk_style_context_get_state: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3147): Gtk-CRITICAL **: gtk_style_context_get_background_color: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3147): Gtk-CRITICAL **: gtk_style_context_get_color: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3196): Gtk-CRITICAL **: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3196): Gtk-CRITICAL **: gtk_style_context_get_state: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3196): Gtk-CRITICAL **: gtk_style_context_get_background_color: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3196): Gtk-CRITICAL **: gtk_style_context_get_color: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3235): Gtk-CRITICAL **: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3235): Gtk-CRITICAL **: gtk_style_context_get_state: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

(/home/neil/firefoxtest/firefox/firefox-bin:3235): Gtk-CRITICAL **: gtk_style_context_get_background_color: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

print.save_print_settings is true
I am attaching a copy of pref.js from my 'blank' profile as print.js

Thanks, that's helpful information. The relevant lines from your prefs.js are:

user_pref("print.printer_Squid2.print_paper_id", "custom_0.5x1.75in_0.5x1.75in");
user_pref("print.printer_Squid2.print_paper_size_unit", 0);
user_pref("print.printer_Squid2.print_paper_width", "  0.50");
user_pref("print.printer_Squid2.print_paper_height", "  1.75");

The print_paper_id line shows that Firefox has selected a custom paper size. The value "0" for print_paper_size_unit means that the paper width and height shown above are in inches. So you getting a tiny paper size seems to be due to that.

Do you know where this paper size is coming from? Is this a size you created and set in Ubuntu/CUPS and made the default paper size? When you first print using a new Firefox profile, Firefox should be querying CUPS/the printer to ask for the printer's default paper size, and using that. If you haven't set this paper size as the default in Ubuntu's/the printer's system settings then I'm not sure where it's coming from. If you have, then Firefox seems to be behaving as it should.

(In reply to Jonathan Watt [:jwatt] from comment #45)

Thanks, that's helpful information. The relevant lines from your prefs.js are:

user_pref("print.printer_Squid2.print_paper_id", "custom_0.5x1.75in_0.5x1.75in");
user_pref("print.printer_Squid2.print_paper_size_unit", 0);
user_pref("print.printer_Squid2.print_paper_width", "  0.50");
user_pref("print.printer_Squid2.print_paper_height", "  1.75");

The print_paper_id line shows that Firefox has selected a custom paper size. The value "0" for print_paper_size_unit means that the paper width and height shown above are in inches. So you getting a tiny paper size seems to be due to that.

Do you know where this paper size is coming from? Is this a size you created and set in Ubuntu/CUPS and made the default paper size? When you first print using a new Firefox profile, Firefox should be querying CUPS/the printer to ask for the printer's default paper size, and using that. If you haven't set this paper size as the default in Ubuntu's/the printer's system settings then I'm not sure where it's coming from. If you have, then Firefox seems to be behaving as it should.

I have no idea where those numbers originated. This was done on a new profile.
I got the same result on my regular firefox nightly profile after I removed all preferences that begain print.printer_Squid2.
By the way, that print was a blank page
I then used the system print dialog to control printing. It showed that weird paper size. I changed the paper size to US Letter and all was well.
Now the preview shows correctly so perhaps it was that weird paper size that caused the problem? By the way, it does take quite some time to render some print previews

(In reply to Lee McFarland from comment #46)

I have no idea where those numbers originated. This was done on a new profile.
I got the same result on my regular firefox nightly profile after I removed all preferences that begain print.printer_Squid2.

In that case, I'm guessing if you open Ubuntu's System Settings, then Printers, then double click on your printer and then select Printer Options, that this paper size is the size selected for the Media Size field? As to how it would get into Ubuntu's system printer settings, I have no idea (Firefox doesn't write to those).

By the way, that print was a blank page

Do you mean you were just testing printing a blank page, or is this another bug where something that shouldn't be blank is blank (in which case can you file a new bug for that)?

I then used the system print dialog to control printing. It showed that weird paper size. I changed the paper size to US Letter and all was well.
Now the preview shows correctly so perhaps it was that weird paper size that caused the problem?

I believe so.

By the way, it does take quite some time to render some print previews

Yeah, we have various bugs open regarding performance issues, such as bug 1663710.

jwatt: Assigning to you for now to get this off the radar of tracked, unassigned bugs since we're obviously still investigating this.

Assignee: nobody → jwatt
Status: NEW → ASSIGNED

Lee, would you be able to answer the following two questions from comment 47? That would help in better understanding how things went wrong in your case and whether we can close this bug, and in understanding whether you were describing a new bug when you were mentioning the blank pages.

(In reply to Jonathan Watt [:jwatt] from comment #47)

(In reply to Lee McFarland from comment #46)

I have no idea where those numbers originated. This was done on a new profile.
I got the same result on my regular firefox nightly profile after I removed all preferences that begain print.printer_Squid2.

In that case, I'm guessing if you open Ubuntu's System Settings, then Printers, then double click on your printer and then select Printer Options, that this paper size is the size selected for the Media Size field? As to how it would get into Ubuntu's system printer settings, I have no idea (Firefox doesn't write to those).

By the way, that print was a blank page

Do you mean you were just testing printing a blank page, or is this another bug where something that shouldn't be blank is blank (in which case can you file a new bug for that)?

Flags: needinfo?(6dnail)

Some how my system setting for the printer was a weird small page. That's why it showed a page size of about 1.75 inches. It also provides a possible explanation for the white page. Firefox was printing as directed, printing a part of the page that fits a piece of paper 1.75 inches - which happened to be white.

Since I changed the system settings for page size to reflect US Letter, the problem is gone.

Flags: needinfo?(6dnail)

Reading the above comments, it seems that unless we want to sanity-check the paper sizes we get back from the system, there is no bug here. We had correctly selected the default paper size and were trying to preview and print it, but as it was so tiny and the printable area was just white, it resulted in a blank sheet.
I guess the only other thing we could do here would be to come up with some visual cues or other UX mitigation to help explain what the user is seeing. As the paper size picker is hidden behind the "more settings" collapsed section, there is no obvious explanation for these kind of symptoms until the user starts digging around. Should paper size be moved outside the "more settings". Or can we display a summary of settings somewhere?

On the basis that this seems to involve corner cases like super small paper sizes in system settings, or copying a profile across platforms, plus the fact that Jonathan added sanity-checking code for some of these settings and that went into beta, I'm not going to block on this for 82.

status-firefox81: affected → wontfix
status-firefox82: affected → fix-optional

(In reply to Sam Foster [:sfoster] (he/him) from comment #51)

Should paper size be moved outside the "more settings"?

Personally I think I'd prefer that, especially given the issues we've been encountering with paper size. If we get more issues like this it given the user a much better chance of noticing a broken paper size and connecting the dots to fix things themselves. I filed bug 1670110 to consider that.

I've reread the comments in this bug and I agree that we're probably done here. If new bug reports of this type get reported we should deal with those in their separate bugs. Hopefully the patches landed for bugs like bug 1665904, bug 1666473 and bug 1669370 will prevent this from happening again though.

Thanks again, Henrik and Lee, for your bug reports and for spending time gathering information to help us diagnose what was going on in your cases. Your time spent on that is much appreciated.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: