User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170302120751 Steps to reproduce: This seems to be common to NYTimes website, but I think it may have happened elsewhere also. I just used https://www.nytimes.com/2017/03/09/movies/t2-trainspotting-interview.html?hpw&rref=movies&action=click&pgtype=Homepage&module=well-region&region=bottom-well&WT.nav=bottom-well to test as follows: 1. On Mac (Yosemite), Page Setup... scaled to for example 80%, Print (PDF, Open PDF in Preview) with Option Ignore Scaling And Shrink To Fit Page Width selected (default?) 2. Repeat 1 but with Option Ignore Scaling And Shrink To Fit Page Width deselected Actual results: 1. Preview appears with very large text, way beyond 80% [attachment1 [details] [diff] [review].pdf] 2. Preview appears with properly sized text (shrunk to fit) These are opposite of what happened in Firefox 50 and previous (more or less) Expected results: 1. Preview appears with properly sized text, shrunk to fit 2. Preview appears with text not shrunk to fit... These are what happens with Firefox 50 and previous (more or less), the longstanding and desirable outcomes.

Could you test with Nightly, I think it has been already fixed (print setup issues on OSX): https://www.mozilla.org/en-US/firefox/nightly/all/

Just tested with FirefoxNightly build (pulled today 55.0a1), and still get similar behavior. When scaled to 80% and Option Ignore Scaling And Shrink To Fit Page Width is selected, I get overly large text when Open PDF in Preview with 55.0a1. Same overly large size as I get with 52.0. When I deselect Option Ignore Scaling And Shrink To Fit Page Width, same 80% scaling, I get more correct text size (although it is larger than what I get with 52.0). With 55.0a1 I get the first 3 pages filled with regular text, with 52.0 I get the first 2 pages filled with regular text (smaller in scale) -- I am unsure which one of these two is actually correct.

Bad news. So as you're able to reproduce on your machine and printer, could you install the tool mozeregression to narrow down a regression range. See http://mozilla.github.io/mozregression/ for details. Run the command "mozregression --good=50" (or older) then for each build downloaded by the tool, make the test and enter in the console if it's good or bad. After the run, copy here the final pushlog from the repository mozilla-inbound.

I did finally get a chance to run mozregression. Last "good" build was 11/11/16, nightly build from 11/12/16 displayed incorrectly. Then I think the tool crashed. Here's the last few lines after I entered the last "bad": 27:18.56 INFO: Narrowed nightly regression window from [2016-11-11, 2016-11-13] (2 days) to [2016-11-11, 2016-11-12] (1 days) (~0 steps left) 27:18.56 INFO: Got as far as we can go bisecting nightlies... 27:18.56 INFO: Last good revision: d38d06f85ef59c5dbb5d4a1a8d895957a78714de (2016-11-11) 27:18.56 INFO: First bad revision: fc104971a4db41e38808e6412bc32e1900172f14 (2016-11-12) 27:18.56 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d38d06f85ef59c5dbb5d4a1a8d895957a78714de&tochange=fc104971a4db41e38808e6412bc32e1900172f14 27:18.56 INFO: Switching bisection method to taskcluster 27:18.56 INFO: Getting mozilla-central builds between d38d06f85ef59c5dbb5d4a1a8d895957a78714de and fc104971a4db41e38808e6412bc32e1900172f14 27:31.08 ERROR: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:590) (This time I used a different test page from nytimes: https://www.nytimes.com/2017/03/06/movies/robert-osborne-dead-turner-classic-movies-host.html?rref=collection%2Fsectioncollection%2Fmovies&action=click&contentCollection=movies&region=stream&module=stream_unit&version=latest&contentPlacement=26&pgtype=sectionfront) My simple test steps were: 1. display test page 2. print 3. change scale to 80 4. open pdf in preview "bad" was when text displayed in overly large characters, "good" was when text displayed in smaller, more normal sized characters Additional steps I could have tried, but they didn't seem necessary to pinpoint bad vs good: 5. back to test page 6. print 7. change scale to 80 8. uncheck ignore scaling and shrink to fit page width 9. open pdf in preview Although as I mentioned previously, the text seems smaller in 52.0 than it used to be in 50 and before, when the scaling actually happens.

I guess the pushlog from mozilla-central is enough, your issue is probably a regression from: Haik Aftandilian — Bug 1303051 - Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac; r=mconley Haik, could you check this regression, please. STR are in the previous comment.

Thanks for reporting this. (In reply to malczewski from comment #0) > Created attachment 8846438 [details] > incorrect results (bug) per test step 1 > > User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) > Gecko/20100101 Firefox/52.0 > Build ID: 20170302120751 > > Steps to reproduce: > > This seems to be common to NYTimes website, but I think it may have happened > elsewhere also. I just used > > https://www.nytimes.com/2017/03/09/movies/t2-trainspotting-interview. > html?hpw&rref=movies&action=click&pgtype=Homepage&module=well- > region&region=bottom-well&WT.nav=bottom-well > > to test as follows: > > 1. On Mac (Yosemite), Page Setup... scaled to for example 80%, Print (PDF, > Open PDF in Preview) with Option Ignore Scaling And Shrink To Fit Page Width > selected (default?) Is your expectation that the 80% will take effect when "Ignore Scaling and Shrink to Fit"? Could you also include a screenshot of the older good output? That might help clear it up. We really need to improve the UI here, but my understanding is that when "Ignore Scaling and Shrink to Fit" is selected, the scaling percentage (80% in this example) is meant to be ignored. i.e., regardless of the % entered, the output is intended to be the same when "Ignore Scaling and Shrink to Fit" is selected. It seems that starting with build 48, Firefox ignored the scaling percentage and this was fixed by Bug 1303051. The comment here https://bugzilla.mozilla.org/show_bug.cgi?id=1303051#c28 explains what was wrong before the bug was fixed. So build 48, 49, and 50 had Bug 1303051. Using your mozregression result, I tried the last good revision (mozregression --launch d38d06f85ef59c5dbb5d4a1a8d895957a78714de) and the first bad revision (mozregression --launch fc104971a4db41e38808e6412bc32e1900172f14) and will include a screenshot of the two (lastgood_vs_firstbad.png) where "last good" is on the left. I consider the PDF generated on the left to be incorrect because the print does not fill the page. For what it's worth, I tested with Google Chrome (57.0.2987.98) and its default settings produced very similar PDFs when compared with Firefox 55's default settings. Thanks.

Screenshot comparing the reported mozregression good (left) and (bad) right, I Left: mozregression --launch d38d06f85ef59c5dbb5d4a1a8d895957a78714de Right: mozregression --launch fc104971a4db41e38808e6412bc32e1900172f14 I consider the PDF generated on the left to be incorrect because the print does not fill the page.

Left hand side is current default (not scaled). Right hand side is scaled.

I rarely use headers or footers. My newest attachment above (testsnap.jpg) shows what default currently does on left hand side (with no headers and no footers). And shows a scaled version on right hand side. This from pdfs I created just prior to filing this bug report, using version 52.0. For (nearly) ever, the right hand side has been the default behavior when scaling has been specified. Up through 11/11/16 daily anyway. And now the opposite is default - ignore scaling, starting with 51 (or more precisely daily 11/12/16 ff.) What I've done for many years when printing or saving as PDF from Firefox has been to update the scaling via Page Setup, Open PDF in Preview to verify, perhaps nudge scaling up or down a few times until it comes out scaled right, and then finally just Print or Save as PDF. (No unchecking or rechecking of boxes necessary.) [I cannot even estimate the hundreds/thousands of times I've done this, nytimes or otherwise.] I can see how Ignore Scaling can be interpreted to mean just print full size. But it should not be the default behavior when scaling has been specified (either by Page Setup or by filling in the Scale box in the Print dialog). And unlike several other values on the bottom half of the Print Dialog, if I disable it, it does not stay disabled, and is back to being checked the next time. So now I have to uncheck it each time I print. Perhaps a "happy" medium would be to at least minimally make the ignore scaling checkbox a sticky one again (like the Appearance ones, and like the Headers and Footers pulldowns are), as I suspect it was at one point (vague recollection of it being so), so one does not have to reset it each time, especially when scaling has been set up previously. In that way the old behavior is still easily available if one wants to just about always print scaled, instead of having to change it pretty much each and every time. And ignore scaling would still be easily available to those who desire that instead. The unscaled text is just about always way too big (left hand side), so it's the rare exception when I actually print at 100%. (FWIW, nytimes is being stubborn for me in other browsers (Chrome and Opera), so I can't try it out on them, as I am unable to log in for some reason.)

Track 53+/54+/55+ as regression.

(In reply to malczewski from comment #9) > I can see how Ignore Scaling can be interpreted to mean just print full > size. But it should not be the default behavior when scaling has been > specified (either by Page Setup or by filling in the Scale box in the Print > dialog). And unlike several other values on the bottom half of the Print > Dialog, if I disable it, it does not stay disabled, and is back to being > checked the next time. So now I have to uncheck it each time I print. > > Perhaps a "happy" medium would be to at least minimally make the ignore > scaling checkbox a sticky one again (like the Appearance ones, and like the > Headers and Footers pulldowns are), as I suspect it was at one point (vague > recollection of it being so), so one does not have to reset it each time, > especially when scaling has been set up previously. In that way the old > behavior is still easily available if one wants to just about always print > scaled, instead of having to change it pretty much each and every time. And > ignore scaling would still be easily available to those who desire that > instead. OK, we'll get that fixed with this bug. Both the "Scale" percent field and the "Ignore Scaling..." checkbox should have their state persisted when set in "Page Setup" so they only have to be set once. That said, I think it makes more sense to remove the "Ignore Scaling ..." checkbox entirely and just respect the "Scale" field all the time. Would anyone be against that? I can't think of a good reason to keep the "Ignore Scaling..." checkbox because setting the "Scale" field to 100% seems pretty well understood. I checked a handful of other applications (TextEdit, Safari, Google Chrome, Evernote) and they just use a scale percentage. OS X Preview does have a toggle for scaling, but it makes sense there because turning on scaling enables other options. > The unscaled text is just about always way too big (left hand side), so it's > the rare exception when I actually print at 100%. OK, and I agree. The text for those articles is bigger than what I would want when printing, but I don't think we should change the default for a fresh profile to be scaled at some percentage because I think that's counter to what users expect. The current defaults (for me at least) produce output similar to Safari and Google Chrome defaults.

The other discrepancy I am seeing is that when printing something that is scaled at 72ish % in Firefox 50 (and longstandingly before that), to get similar sizing (font size, number of pages) with Firefox 52 I have to scale it at 84 %. (This is what I was referring to in last paragraph of Comment 2.) So something else has changed that impacts scaling somewhere between the two versions. Using same scaling percentage, get different output.

It would be good to get a fix for this but it's too late to uplift to beta 53. We could still take a patch for 55/54.

(In reply to malczewski from comment #12) > The other discrepancy I am seeing is that when printing something that is > scaled at 72ish % in Firefox 50 (and longstandingly before that), to get > similar sizing (font size, number of pages) with Firefox 52 I have to scale > it at 84 %. (This is what I was referring to in last paragraph of Comment > 2.) So something else has changed that impacts scaling somewhere between > the two versions. Using same scaling percentage, get different output. I haven't tracked down the difference in scaling here, but build 52 changed the Mac printing code paths significantly with the change to print via the parent process (aka remote printing). (We were already doing this on Windows.) Getting the first version of the Mac content sandbox enabled required turning on printing via the parent.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #13) > It would be good to get a fix for this but it's too late to uplift to beta > 53. We could still take a patch for 55/54. I don't think I'll be able to get to this for a week or two due to some higher priority sandboxing work, but also I don't consider this a new regression. Bug 1303051 made the scaling percentage field functional again after they regressed in build 48 (and possibly earlier) and also made printing respect the "Ignore Scaling..." checkbox. It's just that more improvement with the print and page setup dialogs is needed. My plan is to implement the changes I described in comment 11.

I've written up a patch that does what :haik suggested, removing the "Ignore Scale ..." checkbox (and associated code), however this really deletes the shrink to fit feature of printing. Before we go too deep down this road, wanted to get some feedback on whether that was a good direction from the module peers. It looks the layout team is the closest thing to the owners of printing. Jonathon, if you're not the right folks, just let me know, thanks.

Considering your particular implementation of shrink to fit has been what's kept me using Firefox (probably since there was one), I vote to keep it. Although scaling now seems to be incorrect so when I print and want a specific scaling I revert back to 50. 52 just shrinks it too much with the old scaling numbers. (Fairly certain I had this confirmed the other day when comparing with Safari scaling, but I was doing something else at the time, so didn't pursue.)

My idea to remove the "Ignore Scaling and Shrink To Fit Page Width" checkbox was based on the assumption that printing with Scale set to 100% with the checkbox unchecked is meant to produce the same output as with the checkbox checked. That seemed to be true in experiments I did, but I don't know if that's correct or not. Some guidance on that would help.

(In reply to Haik Aftandilian [:haik] from comment #18) > My idea to remove the "Ignore Scaling and Shrink To Fit Page Width" checkbox > was based on the assumption that printing with Scale set to 100% with the > checkbox unchecked is meant to produce the same output as with the checkbox > checked. That seemed to be true in experiments I did, but I don't know if > that's correct or not. Some guidance on that would help. I think this is primarily an issue for the Firefox front-end/UX people to address, rather than for (e.g.) Layout. But I'll note a few thoughts here, FWIW. I don't think the "Ignore Scaling..." option should be removed, because it means something quite different from setting Scale to 100%. Scale=100% should mean that the page is printed at exactly the size specified by the styles, so that (for example) an element that is 96px wide will print as 1 inch. Other values of Scale would increase/decrease sizes accordingly. Is that the scaling that we get when printing with the Ignore Scaling option UNchecked? (It seems to be, in brief testing just now.) "Ignore Scaling and Shrink To Fit Page Width" should mean that if the content will overflow the width of the page (at its "normal" or 100% size), e.g. because of elements with a large fixed width, then we will automatically apply scaling so that the content fits. Simple testcase: data:text/html,<div style="border:1px solid black;width:5in;height:1in;font:72px times">Hello world If I print this with "Ignore Scaling..." UNchecked and Scale = 100%, the page should have a box that is exactly 5in wide. With "Ignore Scaling and Shrink To Fit Page Width" checked, the box should still be 5in wide (assuming a "normal" paper size such as A4 or US Letter), as it fits comfortably on the page. Now compare: data:text/html,<div style="border:1px solid black;width:25in;height:1in;font:72px times">Hello world With "Ignore Scaling..." UNchecked, the text should remain the same size as in the previous example, the box remains 1in high, and it extends off the side of the page (i.e. the content is clipped and only partially printed). Now, if the "Ignore Scaling..." option is enabled, the page should automatically be scaled such that the box fits entirely within the width; as a result, the text will be much smaller than in the previous example. AFAICS from generating PDF previews of these examples in Nightly, it's behaving as I would expect. The "Ignore Scaling..." checkbox is annoying, in that it doesn't remember my setting (as mentioned in comment 9, etc), but aside from that, it's not clear to me what the bug -- if any -- is here.

(In reply to Jonathan Kew (:jfkthame) from comment #19) > (In reply to Haik Aftandilian [:haik] from comment #18) > > My idea to remove the "Ignore Scaling and Shrink To Fit Page Width" checkbox > > was based on the assumption that printing with Scale set to 100% with the > > checkbox unchecked is meant to produce the same output as with the checkbox > > checked. That seemed to be true in experiments I did, but I don't know if > > that's correct or not. Some guidance on that would help. > > I think this is primarily an issue for the Firefox front-end/UX people to > address, rather than for (e.g.) Layout. But I'll note a few thoughts here, > FWIW. > > I don't think the "Ignore Scaling..." option should be removed, because it > means something quite different from setting Scale to 100%. > > Scale=100% should mean that the page is printed at exactly the size > specified by the styles, so that (for example) an element that is 96px wide > will print as 1 inch. Other values of Scale would increase/decrease sizes > accordingly. Is that the scaling that we get when printing with the Ignore > Scaling option UNchecked? (It seems to be, in brief testing just now.) > > "Ignore Scaling and Shrink To Fit Page Width" should mean that if the > content will overflow the width of the page (at its "normal" or 100% size), > e.g. because of elements with a large fixed width, then we will > automatically apply scaling so that the content fits. Thanks for the explanation. > AFAICS from generating PDF previews of these examples in Nightly, it's > behaving as I would expect. The "Ignore Scaling..." checkbox is annoying, in > that it doesn't remember my setting (as mentioned in comment 9, etc), but > aside from that, it's not clear to me what the bug -- if any -- is here. The scheme we've been using is to have the "Page Setup" dialog set defaults for later "Print" dialogs. For example, setting the paper size in "Page Setup" would change the default resulting in the selected paper size being pre-selected in the next "Print" dialog. Changing the paper size in the "Print" dialog makes the change only apply to that print operation. To follow that scheme, the "Ignore Scaling..." checkbox should also appear in "Page Setup..." and that would be where the default value is set. And the "Scale" field should be grayed out when "Ignore Scaling..." is checked. Otherwise, there is no visual indication to the user that "Scale" is not going to apply and it's very easy to misunderstand the "Ignore Scaling..." checkbox.

While this is a valid bug, it's feels like an edge case. I don't see the value of tracking this for 55. When this is fixed, we can uplift to beta if it is a low-risk fix.

This is out of scope for ESR. Reporter, does this still reproduce on current releases?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #22) > This is out of scope for ESR. Reporter, does this still reproduce on current > releases? I just reproduced the original test with Firefox 58.0.2 on High Sierra 10.13.3, and I get the same erroneous results displayed during Preview in PDF: in particular, way too large text when Ignore Scaling And Shrink To Fit Page Width is selected. I do get reasonably sized text when Ignore Scaling And Shrink To Fit Page Width is not selected and I scale at 80%. Although even worse, when I change from 86% scale to 80% scale, in either Page Setup or the Print Dialog, the 80 doesn't stick, so I repeatedly have to change it in the Print dialog. I don't recall this happening before (granted I'm everyday using current Firefox 52 ESR in Yosemite for the time being, and haven't used more recent versions for quite some time).

Haik, is this still on your radar?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #24) > Haik, is this still on your radar? This dropped off my radar due to some higher priority tasks, but I'll try to make time for in the build 60 time frame. If anyone else is interested in working on this, just let me know.