1276717 - Print Preview and output much smaller than original/document size in one profile

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Firefox Nightly 49.0a1 2016-05-30 on Windows 8.1

In one of my profiles, the print preview and output is much smaller than they should be (works as expected in other profiles). It's because of these preferences:

user_pref("print.print_printer", "mc2550 USB");
user_pref("print.printer_mc2550_USB.print_paper_data", -1);
user_pref("print.printer_mc2550_USB.print_paper_height", " 11,00");
user_pref("print.printer_mc2550_USB.print_paper_name", "");
user_pref("print.printer_mc2550_USB.print_paper_size_type", 0);
user_pref("print.printer_mc2550_USB.print_paper_size_unit", 1);
user_pref("print.printer_mc2550_USB.print_paper_width", "  8,00");
user_pref("print.printer_mc2550_USB.print_scaling", "  2,00");
user_pref("print.printer_mc2550_USB.print_shrink_to_fit", true);

Resetting print_paper_height fixes it because that lets the check at https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/widget/nsPrintOptionsImpl.cpp#536 fail.

The paper_size_unit is in millimeters: https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/widget/nsIPrintSettings.idl#97

How could Firefox's print settings end in such a state?

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

PDFs are shown very small in the preview, for web pages it doesn't finish loading.

Comment 2

[Bob Owen (:bobowen)]

I've had to make changes to the way Windows print settings were copied from the native DEVMODE to our print settings for some of the sandboxing changes.
It's possible that those changes have interacted badly with existing settings and of course there could still be bugs in the new code.

Parts of the old code were basically broken, although generally things happened to work or (as I discovered since) there were add-ons that worked around the bugs.

It looks like the height and width have ended up in inches even though the unit says millimetres.
I had a check in the code for a minimum page size at one point, but I had to remove that because people use very small page sizes for some label/sticker printing sites.

A few questions:
Did you used to set these by hand or use a printing add-on of some sort?
Do you have the hidden pref print.always_print_silent set to true?
If you set the prefs back to these incorrect values, does choosing a different paper in the printer prompt not fix things?

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

It worked as expected in Firefox 46.0.1 and was broken in Firefox 47.0b9 and latest aurora and central.

> Did you used to set these by hand or use a printing add-on of some sort?
No. The profiles purpose is to provide a permanent private browsing Nightly browser, else not much has been changed.

> Do you have the hidden pref print.always_print_silent set to true?
The pref is not set.

> If you set the prefs back to these incorrect values, does choosing a different paper in the printer prompt not fix things?
This fixed it: Opened the printer settings, set paper format from Letter to A4. After that, print preview works as expected. After switching back to Letter, it still works.

I have still a backup of the profile with the issue in case you need it.

Comment 4

[Bob Owen (:bobowen)]

(In reply to Sebastian H. [:aryx][:archaeopteryx] from comment #3)
> It worked as expected in Firefox 46.0.1 and was broken in Firefox 47.0b9 and
> latest aurora and central.

That's slightly worrying, because there are some "fixes" that have landed in 47, for problems other people had in 46.
Although I think this is possibly just because I wouldn't have overwritten the native settings, because of the previous small page size check.

Apart from the paper height these aren't even the default values for the c++ members on the print settings.
My concern here is that in 45 we had settings that were saved to prefs, that even though the were strictly incorrect happened to work.
My changes in 46 caused the settings that you have in this profile, but things continued to work because of the small page size checks.
Those then being removed give the state you experienced and it won't be too uncommon for this to happen to other people.

> I have still a backup of the profile with the issue in case you need it.

I'm at a bit of a loss, but I could have a quick look through the settings and maybe debug to see the differences between 46 and 47.
Would you mind emailing it to me?

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Sent the profile to Bob and was able to reproduce with a new profile locally (but Bob didn't succeed, so it might depend on the printer):

> Would you mind installing Fx45, creating a clean profile and printing to the printer in question (to save the prefs) and then use the profile on Fx46 to print as well. Also repeating this with Fx45 and Fx47.
    45 -> 46 -> 47 works, but 45 -> 47 is broken. Print prefs in the broken profile:
    user_pref("print.printer_mc2550_USB.print_bgcolor", false);
    user_pref("print.printer_mc2550_USB.print_bgimages", false);
    user_pref("print.printer_mc2550_USB.print_duplex", -437918235);
    user_pref("print.printer_mc2550_USB.print_edge_bottom", 0);
    user_pref("print.printer_mc2550_USB.print_edge_left", 0);
    user_pref("print.printer_mc2550_USB.print_edge_right", 0);
    user_pref("print.printer_mc2550_USB.print_edge_top", 0);
    user_pref("print.printer_mc2550_USB.print_evenpages", true);
    user_pref("print.printer_mc2550_USB.print_footercenter", "");
    user_pref("print.printer_mc2550_USB.print_footerleft", "&PT");
    user_pref("print.printer_mc2550_USB.print_footerright", "&D");
    user_pref("print.printer_mc2550_USB.print_headercenter", "");
    user_pref("print.printer_mc2550_USB.print_headerleft", "&T");
    user_pref("print.printer_mc2550_USB.print_headerright", "&U");
    user_pref("print.printer_mc2550_USB.print_in_color", true);
    user_pref("print.printer_mc2550_USB.print_margin_bottom", "0.5");
    user_pref("print.printer_mc2550_USB.print_margin_left", "0.5");
    user_pref("print.printer_mc2550_USB.print_margin_right", "0.5");
    user_pref("print.printer_mc2550_USB.print_margin_top", "0.5");
    user_pref("print.printer_mc2550_USB.print_oddpages", true);
    user_pref("print.printer_mc2550_USB.print_orientation", 0);
    user_pref("print.printer_mc2550_USB.print_page_delay", 50);
    user_pref("print.printer_mc2550_USB.print_paper_data", 9);
    user_pref("print.printer_mc2550_USB.print_paper_height", " 11,00");
    user_pref("print.printer_mc2550_USB.print_paper_name", "");
    user_pref("print.printer_mc2550_USB.print_paper_size_type", 0);
    user_pref("print.printer_mc2550_USB.print_paper_size_unit", 1);
    user_pref("print.printer_mc2550_USB.print_paper_width", "  8,50");
    user_pref("print.printer_mc2550_USB.print_resolution", -437918235);
    user_pref("print.printer_mc2550_USB.print_reversed", false);
    user_pref("print.printer_mc2550_USB.print_scaling", "  1,00");
    user_pref("print.printer_mc2550_USB.print_shrink_to_fit", true);
    user_pref("print.printer_mc2550_USB.print_to_file", false);
    user_pref("print.printer_mc2550_USB.print_to_filename", "");
    user_pref("print.printer_mc2550_USB.print_unwriteable_margin_bottom", 0);
    user_pref("print.printer_mc2550_USB.print_unwriteable_margin_left", 0);
    user_pref("print.printer_mc2550_USB.print_unwriteable_margin_right", 0);
    user_pref("print.printer_mc2550_USB.print_unwriteable_margin_top", 0);
    user_pref("print_printer", "mc2550 USB");

    Differences to the working profile

    Working profile:
    user_pref("print.printer_mc2550_USB.print_paper_height", " -1,00");
    user_pref("print.printer_mc2550_USB.print_paper_width", " -1,00");
    user_pref("print.printer_mc2550_USB.print_resolution", 600);

    Broken profile:
    user_pref("print.printer_mc2550_USB.print_paper_height", " 11,00");
    user_pref("print.printer_mc2550_USB.print_paper_width", "  8,50");
    user_pref("print.printer_mc2550_USB.print_resolution", -437918235);

From Bob:
> So it looks like the issue, is the old invalid settings staying around.
> When I had the check in for the small page size, they didn't get copied to the native DEVMODE and so then got saved correctly as not being used (-1 in the new world).
>
> The resolution probably isn't being updated because the print isn't completing.
>
> I'll see if I can reproduce and think of a solution.
> It's probably too late for 47, and I'm still not sure how many people this might affect.

[Tracking Requested - why for this release]:
It might be too late for Firefox 47, but this could require to be part of a stability release because if the profile is affected and the printer of the user causes these broken print settings (currently an assumption), the print preview for pages like http://www.tagesschau.de/ausland/sieghardt-rupp-101.html gets stuck during generation and the user has to kill Firefox. For other pages and documents, the print preview and output is broken (shrunk to an unrecognizable level)

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Can we still get a telemetry probe into 47.0 RC to measure how big the share of users affected is (at least on beta)?

Comment 7

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Florin, could you please get folks from your team to test this scenario? I am mainly interested in finding out how consistently does this repro. And whether this regressed from beta7/8 to beta9. The sooner we know the sooner we can consider doing a RC2.

Comment 8

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Andrei, can you please check the previous comment. We'd need an assessment on this issue as soon as we can.

Comment 9

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Bob, we pushed RC1 to Beta channel today. So far there are no drivers for RC2 so there may not be a mechanism to put the telemetry in place. What else can we do to judge the impact of this scenario? I tried opening a few PDF documents and looked at the print preview on my win10 laptop and I did not notice a problem. Are there some specific steps to try out to repro this? Thanks!

Comment 10

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hello Sebastian, could you please attach a screen snapshot of the issue? Also, was there a workaround that fixed the print preview? You mentioned some pref settings. Did changing any of those help fix things? I am trying to get more data about the issue to decide whether this needs to block the release or not. Thanks!

Comment 11

[Bob Owen (:bobowen)]

(In reply to Ritu Kothari (:ritu) from comment #9)
> Hi Bob, we pushed RC1 to Beta channel today. So far there are no drivers for
> RC2 so there may not be a mechanism to put the telemetry in place. What else
> can we do to judge the impact of this scenario? I tried opening a few PDF
> documents and looked at the print preview on my win10 laptop and I did not
> notice a problem. Are there some specific steps to try out to repro this?
> Thanks!

I think this is only going to be a problem if you had the old invalid print settings from Fx45.
This could only occur if printing with millimetre size units, so generally not in the US.

If you then hadn't printed at all with Fx46 or went straight to Fx47 and your printer driver accepts 11 by 8.5 mm as a valid page size.

It's difficult to know how large this population might be, because of the different factors.
It can be fixed if you selected a new page size in the print prompt, or by resetting the invalid prefs.

Comment 12

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: screenshot print preview tiny

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: screenshot print preview hanging

(In reply to Ritu Kothari (:ritu) from comment #10)
> Also, was there a workaround that fixed the print preview?You mentioned
> some pref settings. Did changing any of those help fix things?
Yes, resetting the width and height prefs in about:config fixes the issue.

Bob might be on a different OS, I am on Windows 8.1 64 bit and have no option in the default print dialog to change the paper size.

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

For the record, the paper size changes itself automatically from A4 (45) to Letter (47).

Comment 15

[Bob Owen (:bobowen)]

Attachment: Add check for old invalid page size prefs of 11x8.5 mm

Comment 16

[Bob Owen (:bobowen)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=7db6840b11f6

Comment 17

[Bob Owen (:bobowen)]

Looks like ritu is going for a solution for Fx47 of putting this known problem in the release notes with a link to a page explaining a work around.

Would you mind checking to see if setting the paper_size_unit pref to 0 (inches) resolves the issue once you've reproduced it.

That seems like the simplest fix to me (once you've found the pref, which is slightly trickier to explain).

Comment 18

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Given that this issue has workaround(s), we have decided to not fix this for Fx47 because while this is a valid issue we do not believe this ought to block or delay the Fx47 release. I am working with SUMO folks to add an article about this issue and link to it from relnotes where we will mention this as a known issue in Fx47 release.

We should definitely uplift the fix when ready to Aurora/Beta48 and verify it with "Aryx's help (many thanks!).

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

(In reply to Bob Owen (:bobowen) from comment #17)
> Would you mind checking to see if setting the paper_size_unit pref to 0
> (inches) resolves the issue once you've reproduced it.
This fixes it.

Comment 20

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Suggested wording]: Known issue with printing pages of specific sizes (link to this bug)
[Links (documentation, blog post, etc)]: Joni to help create a SUMO article that we can link to.

Comment 21

[Joni Chan]

Thanks for pinging, Ritu, and Bob, for providing the instructions.

We now have a SUMO article for this issue: https://support.mozilla.org/kb/pages-appear-tiny-when-i-print-or-print-preview-firefox

I'll alert our support community in case they get questions/complaints from users.

Comment 22

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Thanks Joni and Bob for getting the article ready so quickly!

Comment 23

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Verified that the Try build fixes the issue if the user hasn't printed (tried to print?) in 47.* before.

Comment 24

[Bob Owen (:bobowen)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0bc73f0ee72c85847932ae11f57a323ea898f0cb
Bug 1276717: Add check for old invalid page size prefs of 11x8.5 mm. r=jimm

Comment 25

[Bob Owen (:bobowen)]

aryx - would you mind testing a slightly different manual fix for the prefs.

Once you have reproduced with a clean profile, does setting the print_paper_height and print_paper_width to -1 also fix the issue?

I think this is a better solution and matches the fix I've just landed.

Comment 26

[Bogdan Maris, Desktop Test Engineering]

I also reproduced this issue on 47 beta 9 up until beta 6 (using beta 5 I can't reproduce) using the prefs from comment 5. 

I also tried with the try build from comment 16 and confirm that changing only paper_size_unit to 0 will resolve this. Also setting print_paper_height and width to -1 will fix this, despite the value of paper_size_unit (1 or 0). Each test was done on Windows 8.1 64-bit, with clean profiles (with prefs from comment 5).

Comment 27

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

(In reply to Bob Owen (:bobowen) from comment #25)
> Once you have reproduced with a clean profile, does setting the
> print_paper_height and print_paper_width to -1 also fix the issue?
Yes, that fixes it.

Comment 28

[Bob Owen (:bobowen)]

Thanks Sebastian and Bogdan for testing that manual work-around and Joni for updating the article.

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #26)
> I also reproduced this issue on 47 beta 9 up until beta 6 (using beta 5 I
> can't reproduce) using the prefs from comment 5. 

Yes, this makes sense, this was a latent problem with these old invalid prefs, which was hidden due to the small page size check that I had to remove for bug 1271900.
That fix landed in beta 6.

Comment 29

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0bc73f0ee72c

Comment 30

[Bob Owen (:bobowen)]

Comment on attachment 8758811 [details] [diff] [review]
Add check for old invalid page size prefs of 11x8.5 mm

Approval Request Comment
[Feature/regressing bug #]:
Old latent issue with printing prefs triggered by change in bug 1271900.

[User impact if declined]:
Users that have printed with mm paper sizes in Fx45 and before and then not until Fx48 might get very small print preview and output page size.

[Describe test coverage new/current, TreeHerder]:
Manual testing by reporter, QA and dev.

[Risks and why]: 
Low: small change that just checks for the specific invalid prefs and corrects.

[String/UUID change made/needed]:
None

Comment 31

[Marcia Knous [:marcia]]

Relnote 49+ added "Fixed an issue with printing pages of specific sizes" and linked to the support article.

Comment 32

[Bob Owen (:bobowen)]

(In reply to Marcia Knous [:marcia - use ni] from comment #31)
> Relnote 49+ added "Fixed an issue with printing pages of specific sizes" and
> linked to the support article.

That article will need to be for Fx47 and possibly afterwards, if people haven't fixed their prefs while using 47, but have still printed.

The relnote for 47 should be something like "Known issue where pages appear tiny when printing or in Print Preview"

If they go straight to Fx48 with the original invalid prefs then the fix I've landed here should sort things out (assuming it gets uplifted).

Comment 33

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Added to Fx47 release notes. I will also comment in Marcia's document to ensure this is *removed* from Fx49 relnotes, it only needs to be in 47 relnotes.

Comment 34

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8758811 [details] [diff] [review]
Add check for old invalid page size prefs of 11x8.5 mm

Taking it in 48 to address this longstanding issue

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4cb85604e7d7

Comment 36

[Marcia Knous [:marcia]]

Clearing ni as the note was removed for 49.

Comment 43

[Bogdan Maris, Desktop Test Engineering]

Does this fix force the values of the prefs \"paper_size_unit\" or \"print_paper_height and _width\" to \"0\" - or \"-1\"?
I just started 48 beta and printed a page (all was good), then I altered the height and width to 11 | 8.5 and then I could reproduce the bug again. I would have expect that Firefox would force size_unit to 0 (by default is 1) or reset the values of height and width after I restart.
I'm not sure how I can verify this fix...

Comment 44

[Bob Owen (:bobowen)]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #43)
> Does this fix force the values of the prefs \"paper_size_unit\" or
> \"print_paper_height and _width\" to \"0\" - or \"-1\"?
> I just started 48 beta and printed a page (all was good), then I altered the
> height and width to 11 | 8.5 and then I could reproduce the bug again. I
> would have expect that Firefox would force size_unit to 0 (by default is 1)
> or reset the values of height and width after I restart.
> I'm not sure how I can verify this fix...

The problem is that 11 by 8.5 mm is actually a valid page size that in theory people might use for printing labels or stickers.
So in order to recognise the invalid prefs I also check for a resolution  outside a range, because the resolution field was not initialised before, so tends to be a large negative or postive figure.
If you also set the resolution to -1 say, that would emulate the old invalid settings.

Comment 47

[Bogdan Maris, Desktop Test Engineering]

Thanks Bob, sorry for the late response but it somehow slipped from my radar. Verified this is fixed on Firefox 49.0 build 3 on Windows 8.1 64 and Windows 10.

Comment 48

[Mark Clements]

This still appears to be an issue in Firefox 50.  For a simple test page, I get very tiny print preview pages with virtually nothing on them (loads of them, for a single page).  For any normal page the browser hangs at this point, presumably because of the sheer number of tiny pages it is trying to render.

I fixed it by setting paper height/width to -1, as per recommended solution.

> The problem is that 11 by 8.5 mm is actually a valid page size that
> in theory people might use for printing labels or stickers.

In theory yes.  In practice?  Well, certainly a lot fewer people than will be affected by this bug (based on a quick Google of the issue(s)).

I think there needs to be a check in the code that if the page size is very small AND the content you are printing results in more than (say) 10 pages, either you fix the issue automatically or, at the very least, pop up a confirmation asking the user to confirm that they really do want to print a million tiny pages.

Also, whatever the outcome, the code should be clever enough not to hang the browser when this happens.