[MAC] Print scaling and shrink to fit page width does not work from page 2

RESOLVED FIXED in mozilla21

Status

()

Core
Printing: Output
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: Hide Kay, Assigned: smichaud)

Tracking

({pp, regression, testcase})

Trunk
mozilla21
x86
Mac OS X
pp, regression, testcase
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox20-)

Details

Attachments

(7 attachments)

(Reporter)

Description

6 years ago
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 http://support.mozilla.com/en-US/kb/Troubleshooting%20extensions%20and%20themes)
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

Updated

6 years ago
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing

Comment 1

6 years ago
This behavior it's on Mac 10.6?
(Reporter)

Comment 2

6 years ago
(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

6 years ago
Hide -> Can you attach a sample of the PDF that is generated? Does the issue also occur if you print to a "real" printer?
(Reporter)

Comment 4

6 years ago
Created attachment 560763 [details]
saved pdf from Nightly
(Reporter)

Comment 5

6 years ago
Created attachment 560764 [details]
print settings
(Reporter)

Comment 6

6 years ago
(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

6 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

6 years ago
Duplicate of this bug: 689695

Comment 9

6 years ago
Confirmed on Firefox/7.0 public release.
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.
Summary: 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

Comment 11

6 years ago
Confirmed still on 7.0.1 for Mac.

Comment 12

6 years ago
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

6 years ago
Confirmed again on 8.0 for Mac.

Updated

6 years ago
Version: 6 Branch → 8 Branch
(Reporter)

Comment 14

5 years ago
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.
(Reporter)

Comment 15

5 years ago
Created attachment 582555 [details]
saved PDF from Thunderbird 8

saved PDF from Thunderbird 8

Comment 16

5 years ago
Also a problem on Firefox 9.0.1.

Comment 17

5 years ago
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

5 years ago
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

5 years ago
Created attachment 592594 [details]
ff 9.0.1/OSX 10.7.2 scale: 75% fit: off

Comment 20

5 years ago
Problem persists on Firefox 11.0 on Mac OS X 10.7.3. Surely more Mac users are troubled by this bug?

Comment 21

5 years ago
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.
Duplicate of this bug: 700812
Version: 8 Branch → Trunk

Comment 23

5 years ago
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

5 years ago
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

5 years ago
Happens with Mac OS X 10.5.8 too.

Comment 26

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
Created attachment 635380 [details] [diff] [review]
Somewhat hacky patch to correct this behaviour.

Comment 30

5 years ago
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

5 years ago
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

5 years ago
A hack is fine with me until the root cause can be determined.

Comment 33

5 years ago
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

5 years ago
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?)
Tracking down the regression range is often helpful for getting traction on bugs.  This tool helps immensely with that: http://mozilla.github.com/mozregression/

However, in this case, I tracked down the regression range:
Last good nightly: 2011-07-19
First bad nightly: 2011-07-20
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a666b4f809f0&tochange=953f9620f395

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.
Blocks: 665218
Keywords: regression
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).
(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
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=97e01c543d70&tochange=b2e3241c7f04
)
Duplicate of this bug: 823079
Any updates on this bug? We're seeing reports about this on SUMO too, e.g. https://support.mozilla.org/questions/936842

Thanks!

Updated

4 years ago
tracking-firefox20: --- → ?
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?
Assignee: nobody → matspal
tracking-firefox20: ? → -

Comment 41

4 years ago
Until the Firefox bug is fixed, we can use Print Edit add-on by DW-dev.
https://addons.mozilla.org/ja/firefox/addon/print-edit/
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

4 years ago
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).
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...
Assignee: matspal → nobody
Keywords: pp, testcase
> 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).
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

4 years ago
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

4 years ago
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

4 years ago
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.
I should be able to get to this this week or next.
Assignee: nobody → smichaud
I've started working on this, and have confirmed that the following revision caused/triggered this bug:

http://hg.mozilla.org/mozilla-central/rev/be8e253130ff

 Bug 665218 - Keep the printing surface until the next BeginPage to avoid null-ptr crash [MacOSX only]. r=roc
author	Mats Palmgren <matspal@gmail.com>
	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.
Created attachment 711995 [details] [diff] [review]
Fix

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.
Attachment #711995 - Flags: review?(matspal)
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

4 years ago
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 on attachment 711995 [details] [diff] [review]
Fix

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
Attachment #711995 - Flags: review?(matspal) → review+
Comment on attachment 711995 [details] [diff] [review]
Fix

Landed on mozilla-inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ffe1610a971a

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

Done and done.
https://hg.mozilla.org/mozilla-central/rev/ffe1610a971a

Should this have a test?
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
> 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

4 years ago
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
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).
(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:
  https://www.mozilla.org/en-US/firefox/channel/#aurora
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

4 years ago
Hurray! Fixed! Took just under 2 years, but still... glad there are softwares out there that listen to their customers.

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