Last Comment Bug 684622 - [MAC] Print scaling and shrink to fit page width does not work from page 2
: [MAC] Print scaling and shrink to fit page width does not work from page 2
: pp, regression, testcase
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal with 9 votes (vote)
: mozilla21
Assigned To: Steven Michaud [:smichaud] (Retired)
: Jet Villegas (:jet)
: 689695 700812 823079 (view as bug list)
Depends on:
Blocks: 665218
  Show dependency treegraph
Reported: 2011-09-04 14:29 PDT by Hide Kay
Modified: 2013-05-14 10:30 PDT (History)
27 users (show)
ryanvm: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

saved pdf from Nightly (99.87 KB, application/pdf)
2011-09-18 00:47 PDT, Hide Kay
no flags Details
print settings (131.87 KB, image/png)
2011-09-18 00:47 PDT, Hide Kay
no flags Details
saved PDF from Thunderbird 8 (187.24 KB, application/pdf)
2011-12-17 11:15 PST, Hide Kay
no flags Details
ff 9.0.1/OSX 10.7.2 scale: 75% fit: off (99.12 KB, application/pdf)
2012-01-29 19:16 PST, falkensmaze
no flags Details
Somewhat hacky patch to correct this behaviour. (2.09 KB, patch)
2012-06-21 11:19 PDT, Tyler Bindon
no flags Details | Diff | Splinter Review
simple testcase (689 bytes, text/html)
2012-10-10 22:06 PDT, Daniel Holbert [:dholbert]
no flags Details
Fix (3.62 KB, patch)
2013-02-08 14:57 PST, Steven Michaud [:smichaud] (Retired)
mats: review+
Details | Diff | Splinter Review

Description Hide Kay 2011-09-04 14:29:38 PDT
The print scaling and the shrink to fit page width does not work for all pages when previewing or saving to a PDF

1) show any web site (e.g. Troubleshooting extensions and themes | Troubleshooting | Firefox Help
2) Print scaling set to less than 100% from Page setup menu
3) Open PDF in Preview or save as PDF

Page 1 is formatted to specified scaling however from page 2  contents are not scaled and cut off

This problem occurs on Firefox 6 to 9, not seen in Firefox 4, 5 and Firefox 3.6.x
Comment 1 Vlad [QA] 2011-09-12 07:08:20 PDT
This behavior it's on Mac 10.6?
Comment 2 Hide Kay 2011-09-17 00:28:28 PDT
(In reply to Vlad [QA] from comment #1)
> This behavior it's on Mac 10.6?

Yes, this problem occurred on 10.6.8 and 10.7.2. I do not have access to 10.5 so I have not confirmed it occurs with this version.
Comment 3 Tim (fmdeveloper) 2011-09-17 15:27:07 PDT
Hide -> Can you attach a sample of the PDF that is generated? Does the issue also occur if you print to a "real" printer?
Comment 4 Hide Kay 2011-09-18 00:47:25 PDT
Created attachment 560763 [details]
saved pdf from Nightly
Comment 5 Hide Kay 2011-09-18 00:47:58 PDT
Created attachment 560764 [details]
print settings
Comment 6 Hide Kay 2011-09-18 00:52:07 PDT
(In reply to Tim (fmdeveloper) from comment #3)
> Does the issue also occur if you print to a "real" printer?

Yes, it occurs when you print to a printer.
Comment 7 Vlad [QA] 2011-09-20 00:37:17 PDT
I can confirm this on 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0) Gecko/20100101 Firefox/6.0 to the latest nightly:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0a1) Gecko/20110915 Firefox/9.0a1

On the releases before Firefox 6, the issue is not present.

Setting resolution to NEW.
Comment 8 detal_2001 2011-09-27 12:50:09 PDT
*** Bug 689695 has been marked as a duplicate of this bug. ***
Comment 9 detal_2001 2011-09-27 12:53:39 PDT
Confirmed on Firefox/7.0 public release.
Comment 10 Daniel Holbert [:dholbert] 2011-09-27 15:04:02 PDT
This is WORKSFORME on linux, using the "Scale" dropdown in Print Preview. (not available on Mac)

Adding [MAC] to summary, since this seems likely to be Mac-only.
Comment 11 detal_2001 2011-09-30 13:58:47 PDT
Confirmed still on 7.0.1 for Mac.
Comment 12 8-bit 2011-10-06 21:19:27 PDT
Repro/confirmed here as well on 7.0.1 for Mac. Pre 6.x does not have any issues. However, when scaling is set to 100% and "Ignore Scaling and Shrink To Fit Page Width" is selected, everything fits to page (best setting I have found for now). Only when a scaling variable <100% is used are there issues from page 2 on. Even if you select "Ignore Scaling and Shrink To Fit Page Width", but have a scaling <100% you will still have the issue - it doesn't respect your selection of ignoring the scaling.

I discussed this on the mozillaZine Forums, and a Win7 user did not have any issues. As stated above it seems to be Mac only.
Comment 13 detal_2001 2011-11-08 14:22:09 PST
Confirmed again on 8.0 for Mac.
Comment 14 Hide Kay 2011-12-17 11:12:59 PST
I see this bug on Thunderbird 8 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 ID:20111105021740), also Earlybird.
Comment 15 Hide Kay 2011-12-17 11:15:09 PST
Created attachment 582555 [details]
saved PDF from Thunderbird 8

saved PDF from Thunderbird 8
Comment 16 David Eschelbacher 2012-01-02 12:31:54 PST
Also a problem on Firefox 9.0.1.
Comment 17 David Wallen 2012-01-20 15:02:59 PST
Problem persists on Firefox 10.0 beta. The page scaling <100% option when it works saves massively on paper and ink. Anyone know of a work around or fix?
Comment 18 falkensmaze 2012-01-29 19:11:06 PST
Having the exact same problem on 9.0.1, Mac OS X 10.7.2. Wish there were a way to print pages 2..N in less than 12pt type.
Comment 19 falkensmaze 2012-01-29 19:16:32 PST
Created attachment 592594 [details]
ff 9.0.1/OSX 10.7.2 scale: 75% fit: off
Comment 20 ev548 2012-03-17 00:10:11 PDT
Problem persists on Firefox 11.0 on Mac OS X 10.7.3. Surely more Mac users are troubled by this bug?
Comment 21 elyod72 2012-03-29 12:40:54 PDT
I can also confirm the issue on Mac OS X 10.6.8. With a scale of 75%. 

In the meantime, my users are forced to use Chrome or Safari to print their reports. Not an ideal situation. 
I fear that management will want to change to one of the other browsers as the company default.
Comment 22 Virgil Dicu [:virgil] [QA] 2012-04-13 06:54:06 PDT
*** Bug 700812 has been marked as a duplicate of this bug. ***
Comment 23 Brian Tung 2012-05-05 09:57:27 PDT
WORKAROUND: File -> Page Setup -> Scale: Set to 100% (or anything above 100%).  Then in the print dialog box, check the box labelled "Ignore Scaling and Shrink to Fit Page Width."  That seems to work for me.
Comment 24 Brian Tung 2012-05-05 09:58:54 PDT
Sorry, that was only for users who had problems with the text fitting the page, not with people who actually want to use scalings under 100%.
Comment 25 daitheflu 2012-06-07 08:23:14 PDT
Happens with Mac OS X 10.5.8 too.
Comment 26 Ralph Seward 2012-06-10 14:09:57 PDT
I am running OSX 10.6, and My Dad is running 10.7. We are both using Firefox 12.0 and we both have this problem. 
We go to File > Page Setup, and set Scale to 150%. Then we got to File > Print, and either Preview or Print. The first page will print (or display in Preview) correctly at scale 150% but all subsequent pages are scaled down to 100%.
In essence, scaling is ignored on all but the first page.
Comment 27 Ralph Seward 2012-06-14 08:31:26 PDT
This problem is specific to newer versions of Firefox on Mac OSX. Print scaling in both Chrome and Safari works as expected, and is consistent across all pages. Unfortunately neither Chrome nor Safari has an option to Print Selection Only.
I just installed Firefox 14.0 and the same problem with print scaling persists.
Comment 28 Tyler Bindon 2012-06-21 11:13:47 PDT
I've looked at this issue and found that in GetSurfaceForPrinter, the graphics context returned from PMSessionGetCGGraphicsContext is not being set to scale for the pages after the first page. The context returned for the first page is right, but thereafter the context isn't set to rescale. I've been able to patch around this issue, by setting the scale of the context after it is created for pages after the first, but it feels a bit hacky to do it that way. I can't figure out why the context is being created incorrectly, though.
Comment 29 Tyler Bindon 2012-06-21 11:19:42 PDT
Created attachment 635380 [details] [diff] [review]
Somewhat hacky patch to correct this behaviour.
Comment 30 Ralph Seward 2012-06-21 12:44:17 PDT
Thank you for figuring this out Tyler. Here's a noob question: Can I patch my local install, or should I just wait for an update to come out?
Comment 31 Tyler Bindon 2012-06-21 12:53:13 PDT
You would probably be best off waiting for an official release. Managing custom patches for your own local install is a nightmare. Just getting to the point where you could build your own copy is tricky and not really easy for non-developers. 

In not a Mozilla developer and I'd never looked at the code before last night, so I'm not really sure what the regular procedure is from here. My current fix really is a hack, but I'm not sure how much time I can devote to finding the root cause. It's stuck in my head right now, though, so I may have trouble forgetting about it.
Comment 32 Ralph Seward 2012-06-21 13:33:20 PDT
A hack is fine with me until the root cause can be determined.
Comment 33 malczewski 2012-10-10 10:01:07 PDT
This is what's keeping me using Firefox 3.x.  Still broken in 15.x.   (Also part of what's keeping me using Snow Leopard.)

Really would like to upgrade, but I need this capability, and no one has managed to do it quite as right as it used to be, long ago, in Firefox.   

(Guess I'll try the hack.)
Comment 34 R. Eric Reuss 2012-10-10 18:53:46 PDT
While I've been able to hobble around this bug for the last year, come January I'll need to either revert back to Firefox 5 or switch to a different browser.

Is there anything I can do to encourage a fix other than voting for it and adding myself to the cc: list?

(Also: I note bug 700812 - marked as a duplicate of this one - had an Importance of 'critical', whereas this one is just 'normal'. If Importance affects whether a bug gets worked on, might it be possible to bump this bug up somehow?)
Comment 35 Daniel Holbert [:dholbert] 2012-10-10 22:00:57 PDT
Tracking down the regression range is often helpful for getting traction on bugs.  This tool helps immensely with that:

However, in this case, I tracked down the regression range:
Last good nightly: 2011-07-19
First bad nightly: 2011-07-20

In that pushlog, this looks like the only possibly-related changeset:
> be8e253130ff	Mats Palmgren — Bug 665218 - Keep the printing surface until the next BeginPage to avoid null-ptr crash [MacOSX only]. r=roc

Marking as regression from that bug and CC'ing Mats.
Comment 36 Daniel Holbert [:dholbert] 2012-10-10 22:06:54 PDT
Created attachment 670242 [details]
simple testcase

Just to be sure there's no ambiguity about fancy web content being involved: here's a trivial testcase (just a few pages of <li> elements, with directions at the top).
Comment 37 Daniel Holbert [:dholbert] 2012-10-10 22:16:01 PDT
(for the record, the mozilla-inbound regression range is the same, and it also includes that same commit for  Bug 665218 that I highlighted in comment 35.
Last good nightly: 2011-07-19
First bad nightly: 2011-07-20
Comment 38 Daniel Holbert [:dholbert] 2012-12-19 09:46:04 PST
*** Bug 823079 has been marked as a duplicate of this bug. ***
Comment 39 David Tenser [:djst] 2012-12-20 09:47:21 PST
Any updates on this bug? We're seeing reports about this on SUMO too, e.g.

Comment 40 Alex Keybl [:akeybl] 2013-01-03 16:26:53 PST
Mats - assigning to you since this is suspected to be a regression from a bug you checked in. Not sure why this has become more prevalent on SUMO recently, likely just that this is a common issue which is now easily queried on Google.

Tyler/David - do we have a keyword like "sumocares" or something similar so that we can track longstanding issues like this outside of release tracking?
Comment 41 Yuichi 2013-01-12 19:28:32 PST
Until the Firefox bug is fixed, we can use Print Edit add-on by DW-dev.
Instead of using the print scaling function of page setup menu (make sure to set it to 100%), go to the print preview menu provided by Print Edit and use its scaling box shown at the top of the preview window, and then print.
Comment 42 Ada [:adalucinet] 2013-01-15 06:02:19 PST
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20130115 Firefox/21.0
Build ID: 20130115030936

I also confirm this wrong behavior on Nightly 21a1 (from 2013-01-15) on Mac OS X 10.8. If I set the print scaling to any number less than 100% (the "Ignore scaling and shrink to fit page width" checkbox doesn't matter if is marked/unmarked), the printed pages have the set scaling only on the first page. It is the same if I print, print preview or save the file (saved as pdf and postscript).
Comment 43 Mats Palmgren (:mats) 2013-01-15 13:22:59 PST
I really have no clue how to fix this other than backing out bug 665218
but it was a topcrash so I don't think that's an option.

Steven, is there any chance you could help here?
There's a testcase and suggested fix attached...
Comment 44 Steven Michaud [:smichaud] (Retired) 2013-01-15 13:31:37 PST
> Steven, is there any chance you could help here?

Possibly eventually.  But for now I'm totally swamped with more urgent bugs, and it's likely to stay that way for a while (at least several weeks).
Comment 45 David Tenser [:djst] 2013-01-16 05:38:24 PST
Do we know the scope of this bug? The report indicates that this affects all Mac installs of Firefox. If so, this is a major bug since scaled printing is broken. I might not be reading into this correctly, but if that is the case, a major function of Firefox is broken and this should be prioritized accordingly.
Comment 46 elyod72 2013-01-16 10:40:59 PST
I agree with David. It is a basic and primary function that is not working. 

My Payroll department cannot utilize Firefox because the routinely need to print reports that have to be scaled to fit on the page. They are instead using Chrome because Chrome does not have this problem.
Comment 47 DJ 2013-01-28 12:03:29 PST
This bug is also in Thunderbird. (v17.0.2) (MAC OS 10.7.5)

Just thought I'd mention it. Sorry if it was obvious to the Mozilla community.
Comment 48 Daidu Tiu 2013-01-29 12:04:27 PST
Our company's web based ERP system was develop on Firefox in 2009. We still using the version 3.6.28 since this problem happen. Fortunately, we shift our browser to Chrome on the end of 2012.
Comment 49 Steven Michaud [:smichaud] (Retired) 2013-01-30 10:08:38 PST
I should be able to get to this this week or next.
Comment 50 Steven Michaud [:smichaud] (Retired) 2013-02-08 11:25:44 PST
I've started working on this, and have confirmed that the following revision caused/triggered this bug:

 Bug 665218 - Keep the printing surface until the next BeginPage to avoid null-ptr crash [MacOSX only]. r=roc
author	Mats Palmgren <>
	Tue Jul 19 14:20:33 2011 +0200 (at Tue Jul 19 14:20:33 2011 +0200)

I probably won't finish with this bug until sometime next week.
Comment 51 Steven Michaud [:smichaud] (Retired) 2013-02-08 14:57:19 PST
Created attachment 711995 [details] [diff] [review]

Now that I've looked at this for a bit, the solution seems rather obvious.

Can you see anything wrong with this patch, Mats?  I've tested it with this bug's testcase and that for bug 665218, without seeing any problems.

I've started a tryserver build, which should be available in a few hours.
Comment 52 Steven Michaud [:smichaud] (Retired) 2013-02-08 14:59:31 PST
Comment on attachment 635380 [details] [diff] [review]
Somewhat hacky patch to correct this behaviour.

This may work too.  Though I haven't tested it yet.

But first let's see what people think of my patch from comment #51.
Comment 53 Tyler Bindon 2013-02-08 15:08:19 PST
My patch was just papering over the issue. Yours looks like it fixes the original null pointer crash without introducing the issues seen in this issue.
Comment 54 Mats Palmgren (:mats) 2013-02-08 16:01:08 PST
Comment on attachment 711995 [details] [diff] [review]

This makes sense, r=mats
nit: please use // for consistency with other comments in this file
super-nit: move the 2nd comment inside the #ifdef
Comment 55 Steven Michaud [:smichaud] (Retired) 2013-02-08 17:17:26 PST
Comment on attachment 711995 [details] [diff] [review]

Landed on mozilla-inbound:

> nit: please use // for consistency with other comments in this file
> super-nit: move the 2nd comment inside the #ifdef

Done and done.
Comment 56 Ryan VanderMeulen [:RyanVM] 2013-02-09 07:48:34 PST

Should this have a test?
Comment 57 Steven Michaud [:smichaud] (Retired) 2013-02-09 09:45:41 PST
> Should this have a [automated] test?

That'd be difficult, and maybe impossible.  This bug becomes visible only after Firefox has fed data to a native (OS X) dialog -- something that can't be queried or controlled from our test engines.
Comment 58 detal_2001 2013-03-08 09:37:22 PST
This is still a bug on 19.0.2 released 3/8/2013. Not sure why this was marked as resolved, unless users have to manually patch it themselves?

Mac, snow leopard, firefox 19.0.2
Comment 59 Daniel Holbert [:dholbert] 2013-03-08 10:06:29 PST
For the purposes of bug-tracking, "fixed" means fixed in our development trunk, not fixed-in-release-builds.  It takes a little while (12-18 weeks) for the fix to make it to users (via testing on Nightly, then Aurora, then Beta, and then it's finally released).

The "Target Milestone" shows what version Nightly was at when this landed there. On this bug, it's set to 21, which means this should be fixed in Firefox 21 (when that makes it to release).
Comment 60 Daniel Holbert [:dholbert] 2013-03-08 10:10:16 PST
(If you're interested in running a pre-release build that includes the fix, you can download Firefox Aurora (which is currently at version 21 and hence includes the fix) from here:
If you can still reproduce the bug in *that* build, *then* there'd be cause for worry about whether this is actually fixed.)
Comment 61 detal_2001 2013-05-14 10:30:07 PDT
Hurray! Fixed! Took just under 2 years, but still... glad there are softwares out there that listen to their customers.


Note You need to log in before you can comment on or make changes to this bug.