Closed Bug 684622 Opened 14 years ago Closed 12 years ago

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

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla21
Tracking Flags:
Tracking Status
firefox20 - ---

People

(Reporter: yattemortors, Assigned: smichaud)

References

Details

(Keywords: platform-parity, regression, testcase)

Attachments

(7 files)

saved pdf from Nightly
99.87 KB, application/pdf
Details
print settings
131.87 KB, image/png
Details
saved PDF from Thunderbird 8
187.24 KB, application/pdf
Details
ff 9.0.1/OSX 10.7.2 scale: 75% fit: off
99.12 KB, application/pdf
Details
Somewhat hacky patch to correct this behaviour.
2.09 KB, patch
Details | Diff | Splinter Review
simple testcase
689 bytes, text/html
Details
Fix
3.62 KB, patch
MatsPalmgren_bugz
: review+
Details | Diff | Splinter Review
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
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
This behavior it's on Mac 10.6?
(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.
Hide -> Can you attach a sample of the PDF that is generated? Does the issue also occur if you print to a "real" printer?
Attached file saved pdf from Nightly —
Attached image print settings —
(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.
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
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
Confirmed still on 7.0.1 for Mac.
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.
Confirmed again on 8.0 for Mac.
Version: 6 Branch → 8 Branch
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.
saved PDF from Thunderbird 8
Also a problem on Firefox 9.0.1.
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?
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.
Problem persists on Firefox 11.0 on Mac OS X 10.7.3. Surely more Mac users are troubled by this bug?
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.
Version: 8 Branch → Trunk
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.
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%.
Happens with Mac OS X 10.5.8 too.
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.
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.
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.
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?
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.
A hack is fine with me until the root cause can be determined.
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.)
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
Attached file 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 )
Any updates on this bug? We're seeing reports about this on SUMO too, e.g. https://support.mozilla.org/questions/936842 Thanks!
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: ? → -
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.
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.
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.
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.
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.
Attached patch Fix — — Splinter 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.
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.
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
Closed: 12 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.
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.)
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.

Attachment

General

Creator:
Created:
Updated:
Size: