Closed Bug 1303051 Opened 3 years ago Closed 3 years ago

Printing Issue: Page Setup (eg scaling) not being respected since upgrade to 48.01 on Mac

Categories

(Core :: Printing: Setup, defect)

48 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 --- fixed
firefox52 --- fixed

People

(Reporter: mobeen.waheed, Assigned: haik, NeedInfo)

References

(Depends on 2 open bugs)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160817112116

Steps to reproduce:

Upgrade or Install Firefox 48.01
1. Select a printer and paper size different from the default paper size from File > Page setup
2. Try to print from any web site and when the dialog box comes up make sure your paper size is the one you selected in the step above.
3. You can do other changes such as removing header and footers
4. Also if your printer has setting such as cutting the paper or opening a cash drawer please change them to cut the paper and open the cash drawer.


Actual results:

- Your paper and size and any of the changes you do will not be respected.
- You will also notice under File > Page Setup the paper size would revert to the default size selected before you did any changes.

*Attaching video of the issue.


Expected results:

- Your paper size and other changes should be respected.
Can't attach video, due to size please reach out to me if you want to see how it is behaving.
Summary: Printing page setup not saving since upgrade to 48.01 on Mac → Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac
Component: Untriaged → Printing: Setup
Product: Firefox → Core
Screen recording of the behaviour can be found here:
https://youtu.be/YJBI3UNwde0
You don't need to write a message to add your email in the CC list, just click on "save changes".
Version 49 also causes the same issues.
Bob, are you aware of this print setup issue on OSX? If that's not your area, could you NI? someone else, please.
Flags: needinfo?(bobowen.code)
(In reply to Loic from comment #7)
> Bob, are you aware of this print setup issue on OSX? If that's not your
> area, could you NI? someone else, please.

I've not dealt with much Mac Printing stuff, although it's possible that some of my cross platform changes have affected this, but the ones up to 48 nearly all landed in 46 ... maybe one or two minor ones in 47.

It could be e10s being activated, but I don't have a Mac to verify, which reminds me, I must order my new laptop.

Mike, could you take a look at this?
Flags: needinfo?(bobowen.code) → needinfo?(mconley)
Mobeen, can you install the tool mozregression to find a regression range in FF48, please.
See http://mozilla.github.io/mozregression/ for details (mozreg is a python 2.7 package)
Run the command mozregression --good=47 then make your test for each build downloaded. Copy here the final pushlog from mozilla-inbound repository.
Flags: needinfo?(mobeen.waheed)
(In reply to Loic from comment #9)
> Mobeen, can you install the tool mozregression to find a regression range in
> FF48, please.
> See http://mozilla.github.io/mozregression/ for details (mozreg is a python
> 2.7 package)
> Run the command mozregression --good=47 then make your test for each build
> downloaded. Copy here the final pushlog from mozilla-inbound repository.


Attempted to do what you said: mozregression --good=47 as well as some other things. Please see the image URL and see what I'm doing wrong. 
https://www.evernote.com/l/ASbiRokc3sFBEa47bysofsuFUPOGIXeXzqEB/image.png

@mobeen not sure if you can repro.
@Vanessa

curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py
sudo easy_install mozregression

Run the three commands above first than run the one Loic said in terminal
This changelog is strange, I don't see any bugfix related to your printing issue. Could you retest, please?
@mobeen

(In reply to Loic from comment #13)
> This changelog is strange, I don't see any bugfix related to your printing
> issue. Could you retest, please?

FWIW, expanding the time slightly around that that one checkin yields https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2016-03-07+03%3A05%3A00&enddate=2016-03-09+03%3A05%3A00

Also reported on Mac is bug 1301765. And I have a user reporting issues.
I don't seem to be able to reproduce this bug in general.

(In reply to christophe.lambert from comment #3)
> Screen recording of the behaviour can be found here:
> https://youtu.be/YJBI3UNwde0

More specifically the steps from this screencast seem to be:

 1. Open a webpage
 2. Modify Page Setup
 3. Open another page in a new window (to show a print version of the
    original page) and, presumably, have that page call window.print()
 4. Open the print output in Preview
 5. Quit Preview
 6. Back in Firefox (in the new window, not the original), open
    Page Setup again
 7. Page Setup has lost the changes

Trying that in a test I knocked up doesn't reproduce the issue though.

Mobeen, would you be able to attach a test webpage to this bug that reproduces the issue for you? If not, how can we get access to the webpage shown in the screencast?
I was able to reproduce this bug using the steps recorded from comment 3. Specifically:

0. Make sure e10s is enabled
1. Open a webpage
2. Modify Page Setup to add a new, custom paper size (I chose 75mm x 75mm)
3. Close Page Setup, and then choose to Print the page
4. Choose the custom 75mm x 75mm page size in the print dialog, and choose to open in Preview as a PDF
5. When Preview opens, make note of the dimensions of the print job

ER:

Generated PDF should have assumed the page to be quite small - 75mm x 75mm.

AR:

In e10s mode, I get the full page printed at a normal letter size.

I think I've narrowed it down to here: http://searchfox.org/mozilla-central/rev/c1e745733c84630821ef53754b627f2c0b0b5202/widget/cocoa/nsDeviceContextSpecX.mm#55

I suspect that the mPageFormat from the nsDeviceContextSpecX is being ignored in the multi-process case - we probably need to serialize it down to the content process, and send it back up when the content process kicks off the print.
Flags: needinfo?(mconley)
Going to see if I can knock this out today.
Assignee: nobody → mconley
@mike would it be possible to get a build with the fix before release so we can test it out with our software?

Also if you want send me an email and I can give you access for testing.
Actually, it looks like this was fixed in bug 1228022, which moves the printing into the parent process.

mobeen.waheed - if you test a Nightly build, or Developer Edition build (where this fix currently is), can you confirm?
Depends on: 1228022
Flags: needinfo?(mobeen.waheed)
@Mike what version will it be on the Nightly build?
(In reply to mobeen.waheed from comment #20)
> @Mike what version will it be on the Nightly build?

Current aurora/developer ed, version 51, available from https://www.mozilla.org/en-US/firefox/channel/#developer
Duplicate of this bug: 1307424
Tried 50 (same issue as before)
Tried 51.0a2 printed normal size but didn't print the entire size of the paper
Tried 52.0a1 same issue, printed normal size but cuts off the paper

In both 51 and 52 the preview will show that the print job is being cut off.

Here's what the print and the preview look like on Windows:https://www.evernote.com/l/ASYRuGYeuaBAGZdD-Fsk7LZLghcMOxGDLSEB/image.png
The only special thing I had to do was uncheck "Shrink to Page Width" in File>Page Setup. 

Here's what the print and the preview look like on Mac (both builds of 51 & 52): https://www.evernote.com/l/ASYFri1X2glJ-Z57SgRxwp-CVtUccFWE58gB/image.png

Notice that the print preview (despite being defined as page size 2.83 x 78.72 inches or 72mm x 2000mm) still prints as if the preview understands the paper size but the image itself prints as if it is on Letter. This is a regression as we could define it as 2.83 x 78.72 (we use this for variable lengths of receipt paper). In build 47 the print preview and the job itself would be defined by this paper size. Now,  the image prints as if it wanted to be on letter paper.
Looks like it's not quite fixed and either way we might need a fix for 50, I don't think we'd want to uplift bug 1228022.

Bug 1228022, possibly helps because we'd now be holding and using a version of the print settings in the parent.
But we still need to use the print settings in the child to create a compatible off screen surface when we're recording the commands in the child.
If we don't have all the relevant information in the child for Mac then maybe that is what's going wrong?

We might need to override [1] for Mac as well, if this base implementation doesn't return the correct surface size, because that's what we use in the child for the dummy one.

[1] https://hg.mozilla.org/mozilla-central/file/3000c58d1d8e/widget/nsPrintSettingsImpl.cpp#l918
Flags: needinfo?(mconley)
Before I forget to ask, is an automated test possible?
haik has graciously offered to investigate this.
Flags: needinfo?(mconley) → needinfo?(haftandilian)
Re-assigning for now.
Assignee: mconley → haftandilian
Flags: needinfo?(haftandilian)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac → Printing Issue: Page Setup (eg scaling) not being respected since upgrade to 48.01 on Mac
The two problems that need fixing here are

Problem 1) In the print dialog, changing the paper size, orientation, or scaling doesn’t affect the output.

Problem 2) Change made in the page setup dialog don’t persist as defaults when the print dialog is opened later. Specifically, the paper size, scaling factor, and orientation (landscape vs portrait) selected in the page setup dialog are not pre-selected when the print dialog is opened. i.e., the intent is that the defaults for the print dialog are set with page setup dialog.

(Problem 2 is a little different  on Nighty where remote printing is enabled. To disable remote printing on Nightly, set print_via_parent=false and security.sandbox.content.level=0).

Problem 1 happens because those values in the native OS X NSPrintInfo object are not included in the serialization in nsPrintOptionsX::SerializeToPrintData and nsPrintOptionsX::DeserializeToPrintSettings. After the print dialog is displayed in the parent, the nsPrintOptionsX is sent back to the child process for the printing to progress, but parts of NSPrintInfo are lost. The child ends up using the default OS printing settings.

Problem 2 happens because the child process fails to build a NSPrintInfo from preferences and as a result always sends a default NSPrintInfo to the parent to display the print dialog. The serialization issue in problem 1 also would affect the child sending an NSPrintInfo to the parent, but we hit two problems before that. First, browser-content.js:getPrintSettings() always returns null because there is Mac no widget factory for nsIPrintSettingsService.defaultPrinterName and hence an exception is triggered resulting in content starting with a null print settings object. After working around that problem, the second problem is that the child can’t read the "print.macosx.pagesetup-2” pref which contains the saved native print data. That’s because the pref is larger than 4K and therefore not part of the message that the parent sends to the child at startup containing all the prefs. In the parent, in Preferences::GetPreferences, prefs larger than MAX_ADVISABLE_PREF_LENGTH (4 * 1024) are silently skipped so the content never receives this pref.

The print.macosx.pagesetup-2 pref contains an encoded OS X PMPrintSettings object which is an opaque type. I tried using BZ4 compression and that reduced the pref size to around 1K, but that’s not a great solution because the size of the object is still beyond our control.

The child never actually needs to use the PMPrintSettings so we could instead change the parent to always load the pref before displaying the print dialog. This way, the print dialog will always start with the correct page setup value selected. The child won’t need to load the pref itself. Then, fixing the serialization issues will allow the parent to send back the print dialog NSPrintInfo data to the child to perform the printing.
Any feedback on this would be helpful.

Posted a fix to reviewboard. One of the changes is that the code overwrites the scaling percentage specified in the print dialog when "Ignore Scaling and Shrink to Fit Page Width" is checked. I think that is the intended effect of the checkbox. I compared with build 47, but the checkbox seems to have no effect there. (It would be nice if the scaling percentage input field was grayed out when the checkbox is checked, but I'm not attempting to change that here.)

There's a known issue with scaling on Nightly that will need to be addressed in a follow up bug. On Nightly, when the "Ignore Scaling" checkbox is unchecked and a scale percentage other than 100% is used. The scaling is incorrect. Instead of scaling the content down and then repaginating, it's as if each page is rendered at 100% and then scaled down without repagination. Nightly works differently because remote printing is used with e10s on Nightly only (for now).

To test how this will work on Aurora/Beta/Release, first set printing_via_parent=false, security.sandbox.content.level=0 and restart the browser.
Haik, this won't come soon enough to fix these issues but, ... the next printing work I'm going to be looking at is to do all access to print devices in the parent.

This will mainly involve changing things to do the print settings / dialog stuff up front in the parent.
See Also: → 1314780
(In reply to Bob Owen (:bobowen) from comment #31)
> Haik, this won't come soon enough to fix these issues but, ... the next
> printing work I'm going to be looking at is to do all access to print
> devices in the parent.
> 
> This will mainly involve changing things to do the print settings / dialog
> stuff up front in the parent.

Good to know. From what I can tell, content processes don't need access to the native print settings and the pref they're stored in. So it would be nice to clean that up. I can help with the Mac side.
Comment on attachment 8806177 [details]
Bug 1303051 - Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac;

https://reviewboard.mozilla.org/r/88238/#review89846

::: widget/cocoa/nsCocoaUtils.h:34
(Diff revision 2)
>  enum {
>    NSEventPhaseMayBegin    = 0x1 << 5
>  };
>  #endif
>  
> +#define COCOA_PAGESIZE_POINTS_PER_INCH  72.0

This hard codes the paper size to be 72 units per inch (found empirically), but I don't know if this is correct. The Apple docs for the paper size say "The size is measured in points in the user coordinate space." I'm looking into whether or not the units should be derived from the view resolution or something similar.
Comment on attachment 8806177 [details]
Bug 1303051 - Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac;

https://reviewboard.mozilla.org/r/88238/#review89846

> This hard codes the paper size to be 72 units per inch (found empirically), but I don't know if this is correct. The Apple docs for the paper size say "The size is measured in points in the user coordinate space." I'm looking into whether or not the units should be derived from the view resolution or something similar.

Changed the code to use the resolution from the main window to determine the scaling factors (for width and height) to use to convert NSPrintInfo paper sizes to inches.
Blocks: 1315121
Is their a version in Nightly or a Dev build we can use to test out if it's still happening?
(In reply to mobeen.waheed from comment #37)
> Is their a version in Nightly or a Dev build we can use to test out if it's
> still happening?

Sure, I'll post an unofficial Aurora/Developer-Edition build shortly. Any testing would be a great help. The changes have not gone through code review yet so they aren't available in Nightly.
Flags: needinfo?(haftandilian)
thx @haik appreciate it.
Here's an Aurora 51 build with the fix that is under review now.

  https://archive.mozilla.org/pub/firefox/try-builds/haftandilian@mozilla.com-c6162fea91dcae229be1c7676bbe4d755298bb8e/try-macosx64/firefox-51.0a2.en-US.mac.dmg

I've been told the builds get auto-deleted after a week or so.

These builds aren't signed and so, by default, they won't run with just a double-click. On pre-Sierra OS X versions, you have to right-click and Open and then allow the app to run. Sierra is more strict about unsigned-applications and you have to run the run the spctl command with sudo as follows. (If you're uncomfortable with this, I'll figure something else out.)

  $ sudo spctl --master-disable
  <Open the browser>
  $ sudo spctl --master-enable

Remember to re-enable! Once the app has been run, you can re-enable the restrictions and still be able to launch it.

To be sure you're not running something I maliciously built, you can get to this binary by starting at my try results link, clicking on the optimized build, and then the Build "x86_64 osx-10-7 mac" link. And you can see the source changes too.

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

Checksum:

  $ shasum -a 256 firefox-51.0a2.en-US.mac.dmg 
  8f46774de97d8e80104ad4cdcf59ccd346b18f440d55197526f561855908b803
  firefox-51.0a2.en-US.mac.dmg

Thanks!
Flags: needinfo?(haftandilian)
@haik so I ran some test on the developper version you posted, and this is what I get.

1. When I set a paper size from File > Page Setup. The page size reverts back to US Letter which is what it was when I first navigated to that dialog box.

2. When I go to print and the dialog box comes up it has US Letter for Default setting, and that is normal because the step earlier isn't respecting it.

3. If I change the paper size on the print dialog box and save it as a preset it will save my paper size and respect it. I can go back and use that preset again and the page size will be respected.

So it fixed some of the issue from earlier, however the one issue that is still happening is that File > Page Setup isn't saving the paper size you want to set on the browser.

Please let me know if you would like me to post a video of this behavior if the above results aren't clear.
(In reply to mobeen.waheed from comment #41)
> @haik so I ran some test on the developper version you posted, and this is
> what I get.
> 
> 1. When I set a paper size from File > Page Setup. The page size reverts
> back to US Letter which is what it was when I first navigated to that dialog
> box.
> 
> 2. When I go to print and the dialog box comes up it has US Letter for
> Default setting, and that is normal because the step earlier isn't
> respecting it.
> 
> 3. If I change the paper size on the print dialog box and save it as a
> preset it will save my paper size and respect it. I can go back and use that
> preset again and the page size will be respected.
> 
> So it fixed some of the issue from earlier, however the one issue that is
> still happening is that File > Page Setup isn't saving the paper size you
> want to set on the browser.
> 
> Please let me know if you would like me to post a video of this behavior if
> the above results aren't clear.

The video might help. Maybe there's something different about how I'm testing.

First though, could you try testing that binary with a fresh new profile? I can't think how that would affect this, but just in case it tells us something.

After you click OK in the Page Setup dialog, the paper size and other state from the dialog gets saved in a pref and that is re-used when the Page Setup dialog is displayed again or when the Print dialog is displayed. If there was some issue saving the pref, that could explain it.
Flags: needinfo?(mobeen.waheed)
I can reproduce this in latest Nightly using any preset size or custom size.  When going to Print Preview the setting is not respected.  (Though it is still set in Page Setup dialog)

I cannot reproduce the issue with Haik's DevEd build in comment #40.  Changing the paper size is respected by the Print Preview dialog and is reflected in correct size pages when saving as a PDF.
Comment on attachment 8806177 [details]
Bug 1303051 - Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac;

https://reviewboard.mozilla.org/r/88238/#review91614

This looks okay to me, though I didn't test it locally. Our printing testing story is a sad tale. :/ Glad to see tracy has confirmed this has fixed things though.

::: widget/cocoa/nsPrintDialogX.mm:119
(Diff revision 3)
> +  if (win) {
> +    NSDictionary *devDesc = [win deviceDescription];
> +    if (devDesc) {
> +      NSSize res = [[devDesc objectForKey: NSDeviceResolution] sizeValue];
> +      float scale = [win backingScaleFactor];
> +      settingsX->SetInchesScale(res.width/scale, res.height/scale);

Nit - spaces on either side of the /'s
Attachment #8806177 - Flags: review?(mconley) → review+
Comment on attachment 8806177 [details]
Bug 1303051 - Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac;

https://reviewboard.mozilla.org/r/88238/#review91614

> Nit - spaces on either side of the /'s

Thanks, Mike.

Fixed the spacing, added check to prevent divide by zero, added more comments.
(In reply to Haik Aftandilian [:haik] from comment #42)
> (In reply to mobeen.waheed from comment #41)
> First though, could you try testing that binary with a fresh new profile? I
> can't think how that would affect this, but just in case it tells us
> something.

Mobeen, could you check if you have "print.save_print_settings" set to false? If that is set to false, that would cause problem 1 you described in comment 41. It's true by default for new profiles.

The pref is intended to save settings after each print operation or page setup dialog.

With my proposed patch, it's not going to cause print settings to be saved after a print operation. I'll adjust the fix to do that. i.e., print settings will be saved after the Page Setup dialog is displayed and after the Print dialog is displayed if the dialog was closed successfully. And setting print.save_print_settings=false will prevent saving in both cases.

The benefit of using page setup will be that it will allow the user to set the defaults without having to print something.

New patch on the way.
See Also: → 855889
Updated the code to save the print settings after the print dialog is shown as long as print.save_print_settings==true. Changed reading/writing of the print settings pref to use nsIPrintSettingsService instead of calling methods on the nsPrintSettingsX object directly. The change is minor so I'm not re-requesting review.
Going ahead with push to Nightly. I suspect Moheen's issue with the fix was due to print.save_print_settings set to false and will try to confirm before uplifting this.
@haik I ran the test again, and my print.save_print_settings was set to True. That being said can you send me a clear profile I can add and test the new build with just to be sure.
(In reply to mobeen.waheed from comment #52)
> @haik I ran the test again, and my print.save_print_settings was set to
> True. That being said can you send me a clear profile I can add and test the
> new build with just to be sure.

OK, I'll get a new Aurora build for you to test. Could you check what the value of the pref "print.use_global_printsettings" is in the profile you used to test?
@haik yes it's their and it's set to true.
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/1fdb1f8a9ddd
Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac; r=mconley
Keywords: checkin-needed
OK, here's the fix built for Aurora.

https://archive.mozilla.org/pub/firefox/try-builds/haftandilian@mozilla.com-7377cefa483e79ed9ba54dd4cc2d8cb51aaf435c/try-macosx64/firefox-51.0a2.en-US.mac.dmg

  $ shasum -a 256 firefox-51.0a2.en-US.mac.dmg 
  472e499e19c1e8838148d87df98bad7a2acc355902b1c2dea90da84835fae870 firefox-51.0a2.en-US.mac.dmg

After opening the .dmg, I copied the "FirefoxDeveloperEdition" app to the Desktop. Then I run Firefox with -P so the profile manager opens and from there you can create a completely new profile and launch the browser using it. For example,

  $ ~/Desktop/FirefoxDeveloperEdition.app/Contents/MacOS/firefox -P
https://hg.mozilla.org/mozilla-central/rev/1fdb1f8a9ddd
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Did we forget to nominate this for uplift?
Flags: needinfo?(haftandilian)
I had wanted to be conservative with this fix because the affected printing code is brittle due to low automated test coverage. So far, this code is working well and at least two more bugs have been filed which appear to fixed by this bug:

  Bug 1321053 my cannon pixma printer will no longer print in grayscale,
              it will with safari, this is not a printer problem

  Bug 1326531 can't print double-sided on some printers

So I'm working on getting the uplift done now. Thanks.
Flags: needinfo?(haftandilian)
Duplicate of this bug: 1321053
Duplicate of this bug: 1326531
No longer depends on: 1228022
Comment on attachment 8806177 [details]
Bug 1303051 - Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac;

Approval Request Comment
[Feature/Bug causing the regression]:
e10s

[User impact if declined]:
Many print options don't work as expected on Mac: users with e10s enabled can't print in black and white directly from Firefox, can't print in duplex directly from Firefox, can't print in non-default paper sizes, and can't do scaled prints.

[Is this code covered by automated tests?]:
Mostly no (reftests cover a small part of this functionality)

[Has the fix been verified in Nightly?]:
Yes, first integrated November 9th, 2016.

[Needs manual test from QE? If yes, steps to reproduce]: 
No

[List of other uplifts needed for the feature/fix]:
None

[Is the change risky?]:
Low risk, isolated to printing on Mac.

[Why is the change risky/not risky?]:
The changes are isolated to printing on Mac.

[String changes made/needed]:
None.
Attachment #8806177 - Flags: approval-mozilla-beta?
Comment on attachment 8806177 [details]
Bug 1303051 - Printing Issue: Page Setup not being respected since upgrade to 48.01 on Mac;

Let's fix Page Setup!  Should be in 51 beta 13 next week.
Attachment #8806177 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Depends on: 1330643
Depends on: 1346649

HP Printer Customer service https://www.hpprintersupporthelpline.com/

Bugbug thinks this bug is a regression, but please revert this change in case of error.

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