mobeen.waheed Reporter
	Description • 8 years ago

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.

	mobeen.waheed Reporter
	Comment 1 • 8 years ago

Can't attach video, due to size please reach out to me if you want to see how it is behaving.

	christophe.lambert
	Comment 3 • 8 years ago

Screen recording of the behaviour can be found here:
https://youtu.be/YJBI3UNwde0

	Loic
	Comment 5 • 8 years ago

You don't need to write a message to add your email in the CC list, just click on "save changes".

	vanessa.knight
	Comment 6 • 8 years ago

Version 49 also causes the same issues.

	Loic
	Comment 7 • 8 years ago

Bob, are you aware of this print setup issue on OSX? If that's not your area, could you NI? someone else, please.

	Bob Owen (:bobowen)
	Comment 8 • 8 years ago

(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?

	Loic
	Comment 9 • 8 years ago

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.

	vanessa.knight
	Comment 10 • 8 years ago

(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.

	mobeen.waheed Reporter
	Comment 11 • 8 years ago

@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

	mobeen.waheed Reporter
	Comment 12 • 8 years ago

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be593a64d7c6a826260514fe758ef32a6ee580f7&tochange=7a6ad98de34e7374188231aec6a50eff87781913

Above is the final Pushlog

	Loic
	Comment 13 • 8 years ago

This changelog is strange, I don't see any bugfix related to your printing issue. Could you retest, please?

	Wayne Mery (:wsmwk)
	Comment 14 • 8 years ago

@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.

	Jonathan Watt [:jwatt]
	Comment 15 • 8 years ago

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?

	Mike Conley (:mconley) (:⚙️)
	Comment 16 • 8 years ago

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.

	Mike Conley (:mconley) (:⚙️)
	Comment 17 • 8 years ago

Going to see if I can knock this out today.

	mobeen.waheed Reporter
	Comment 18 • 8 years ago

@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.

	Mike Conley (:mconley) (:⚙️)
	Comment 19 • 8 years ago

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?

	mobeen.waheed Reporter
	Comment 20 • 8 years ago

@Mike what version will it be on the Nightly build?

	Wayne Mery (:wsmwk)
	Comment 21 • 8 years ago

(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

	vanessa.knight
	Comment 23 • 8 years ago

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.

	Bob Owen (:bobowen)
	Comment 24 • 8 years ago

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

	Wayne Mery (:wsmwk)
	Comment 25 • 8 years ago

Before I forget to ask, is an automated test possible?

	Mike Conley (:mconley) (:⚙️)
	Comment 26 • 8 years ago

haik has graciously offered to investigate this.

	Mike Conley (:mconley) (:⚙️)
	Comment 27 • 8 years ago

Re-assigning for now.

	Haik Aftandilian [:haik] Assignee
	Comment 28 • 8 years ago

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.

	Haik Aftandilian [:haik] Assignee
	Comment 30 • 8 years ago

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.

	Bob Owen (:bobowen)
	Comment 31 • 8 years ago

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.

	Haik Aftandilian [:haik] Assignee
	Comment 33 • 8 years ago

(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.

	Haik Aftandilian [:haik] Assignee
	Comment 34 • 8 years ago
mozreview-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/#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.

	Haik Aftandilian [:haik] Assignee
	Comment 36 • 8 years ago
mozreview-review-reply

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.

	mobeen.waheed Reporter
	Comment 37 • 8 years ago

Is their a version in Nightly or a Dev build we can use to test out if it's still happening?

	Haik Aftandilian [:haik] Assignee
	Comment 38 • 8 years ago

(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.

	mobeen.waheed Reporter
	Comment 39 • 8 years ago

thx @haik appreciate it.

	Haik Aftandilian [:haik] Assignee
	Comment 40 • 8 years ago

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!

	mobeen.waheed Reporter
	Comment 41 • 8 years ago

@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.

	Haik Aftandilian [:haik] Assignee
	Comment 42 • 8 years ago

(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.

	Tracy Walker [:tracy]
	Comment 43 • 8 years ago

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.

	Mike Conley (:mconley) (:⚙️)
	Comment 44 • 8 years ago
mozreview-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

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

	Haik Aftandilian [:haik] Assignee
	Comment 46 • 8 years ago
mozreview-review-reply

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.

	Haik Aftandilian [:haik] Assignee
	Comment 47 • 8 years ago

(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.

	Haik Aftandilian [:haik] Assignee
	Comment 49 • 8 years ago

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.

	Haik Aftandilian [:haik] Assignee
	Comment 50 • 8 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=32edefd4405bd38c533b32d91268787a7673d88f&selectedJob=30787261

	Haik Aftandilian [:haik] Assignee
	Comment 51 • 8 years ago

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.

	mobeen.waheed Reporter
	Comment 52 • 8 years ago

@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.

	Haik Aftandilian [:haik] Assignee
	Comment 53 • 8 years ago

(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?

	mobeen.waheed Reporter
	Comment 54 • 8 years ago

@haik yes it's their and it's set to true.

	Pulsebot
	Comment 55 • 8 years ago

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

	Haik Aftandilian [:haik] Assignee
	Comment 56 • 8 years ago

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

	Carsten Book [:Tomcat]
	Comment 57 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/1fdb1f8a9ddd

	Ryan VanderMeulen [:RyanVM]
	Comment 58 • 8 years ago

Did we forget to nominate this for uplift?

	Haik Aftandilian [:haik] Assignee
	Comment 59 • 8 years ago

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.

	Haik Aftandilian [:haik] Assignee
	Comment 62 • 8 years ago

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.

	Haik Aftandilian [:haik] Assignee
	Comment 63 • 8 years ago

Beta try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0697831cbba63c90acd50f330c3959547f8444ff&selectedJob=66241604

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 64 • 8 years ago

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.

	Ryan VanderMeulen [:RyanVM]
	Comment 65 • 8 years ago
bugherder uplift

https://hg.mozilla.org/releases/mozilla-beta/rev/a482ea2517c4