dw-dev Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170302120751

Steps to reproduce:

This is a follow-on from Bug 1324064 (see comments 21 & 22).

In mid-February, I released my add-on Print Edit 17.7 to make it compatible with the fix in Bug 1324064.

In early March, I have released Print Edit 17.10 with a workaround for Bug 1352841.

Recently, I have received a bug report from another user who is using Firefox 52.0.1 and Print Edit 17.10 running on iMac Sierra 10.12.3. This user says that Print Edit no longer prints to the desired scale. It now always prints to the default 100%.  It is not clear whether print previewing is also always at 100%.

Please note: Normally, none of Firefox's print preview functionality is available when using Mac OS X, but Print Edit makes that functionality available on Mac OS X.


Actual results:

On Mac OS X, pages are always printed at 100%, ignoring the scaling.


Expected results:

On Mac OS X, pages should be printed at the correctly scaled size.

	Bob Owen (:bobowen)
	Comment 1 • 7 years ago

haik - sounds like we might have some compatibility issues with printing via the parent on Mac and the Print Edit addon, would you mind having a look?

	Haik Aftandilian [:haik] Assignee
	Comment 2 • 7 years ago

Hi, this sounds like it could be similar to the issue with Bug 1346649 "Ignore scaling Print option working opposite of expected on Mac OSX".

Build 52 made Mac printing respect the "Ignore Scaling and Shrink To Fit Page Width" check box--meaning that if the check box is selected, the scaling percentage will be ignored. Is it possible, the user had the "Ignore Scaling..." check box selected? If that's the case, we should consider this a dupe of 1346649.

Unfortunately, this isn't very intuitive and I plan to remove the "Ignore Scaling and Shrink To Fit Page Width" check box from the print dialog in Bug 1346649. More discussion on 1346649. (If you have any comments on the usefulness of "Ignore Scaling", please add them to 1346649.)

I did a few tests with the Print Edit extension version 17.11 and scaling worked for me when "Ignore Scaling" was not checked.

	dw-dev Reporter
	Comment 3 • 7 years ago

I think it might be useful for you to see the user's original problem report:

"I am using iMac Sierra (10.12.3). It seems that since Firefox update to 52.0.1 or perhaps it was the update for Print Edit extension (17.10) Print Edit no longer prints to desired scale. It now always prints to the default 100%. Tried approaching this issue by changing the scale in the system print dialogue box instead but the results were terrible. Is there an issue here that you are aware of or is it singular to my situation?"

I don't think this provides any more information, but I thought it might be useful.

I will ask the user whether he had the "Ignore Scaling and Shrink To Fit Page Width" check box selected.

	Loic
	Comment 4 • 7 years ago

There is bug 1303051 too.

	dw-dev Reporter
	Comment 5 • 7 years ago

Here are the user's answers to the two questions:

1. When you preview the page in the print preview window, is the scale correctly applied there, or is it also 100% ?

   "Yes, the PrintEdit print preview window shows scaling perfectly as always."


2. Did you have the 'Ignore Scaling and Shrink To Fit Page Width' check box enabled (ticked) in the print dialog.

   "No difference. The 'Ignore Scaling and Shrink to Fit Page Width' enabled (ticked) or disabled (not ticked)
    yields exactly the same result. Both print at 100%. It's as though Firefox print dialogue is not communicating
    with Print Edit scaling."

	dw-dev Reporter
	Comment 6 • 7 years ago

I have received several more bug reports from users who are experiencing the same problem.

Are you able to confirm that this is a bug in Firefox 52.0 ?

	Haik Aftandilian [:haik] Assignee
	Comment 7 • 7 years ago

(In reply to dw-dev from comment #6)
> I have received several more bug reports from users who are experiencing the
> same problem.
> 
> Are you able to confirm that this is a bug in Firefox 52.0 ?

It's sounding like a build 52 regression, but I have to spend some more time on this before I understand what's going on.

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

On Nightly 55, this problem is happening because we're missing an nsPrintSettingsX::GetScaling() implementation. Bug 675709 added the nsPrintSettingsX::SetScaling() override to set the scale value in the OS X native print settings object, but the GetScaling() call still returns the default value from the base class. Will post a patch.

Needs more debugging to determine what was causing the problem in 52+ before 675709 landed in build 54.

	Haik Aftandilian [:haik] Assignee
	Comment 9 • 7 years ago

Adds nsPrintSettingsX::GetScaling(). Tested with Print Edit 18.2.

	Haik Aftandilian [:haik] Assignee
	Comment 10 • 7 years ago

I haven't been able to reproduce this with build 52. mozregression narrowed this down to

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=629a2481d51916ade2716a5155d0cee83475aaca&tochange=17414d851efb55e58879157ef16f525a2e73ab0b

  Bug 1331857 - Create class BasicRenderingContext2D. r=gwright
  Bug 675709 - Export the constants for paper orientation. r=haik
  Bug 1328512 followup 2 - Update expectation of style system tests for stylo. DONTBUILD

Given comment 8, this bug appears to be a regression introduced by 675709.

	Haik Aftandilian [:haik] Assignee
	Comment 13 • 7 years ago

Update to comment 10. I used Print Edit 17.10 for the mozregression check. With version 18.2, older versions of Firefox didn't work. The Print Preview option opened a new blank tab with no scaling menu.

	Haik Aftandilian [:haik] Assignee
	Comment 14 • 7 years ago

dw-dev, could you verify Print Edit scaling works as expected with the build generated here?

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

	dw-dev Reporter
	Comment 15 • 7 years ago

This bug was reported to me by a user of Print Edit.  I do not have access to a Mac OS X system, so I have never actually reproduced this bug myself.  So I am unable to confirm whether scaling works as expected with the new build.

	Hiroshi Hatake [:cosmo0920]
	Comment 16 • 7 years ago

I could reproduce this issue with 56.0a1 nightly and confirmed haik's Try artifact solves this Bug.

	Hiroshi Hatake [:cosmo0920]
	Comment 18 • 7 years ago
mozreview-review

Comment on attachment 8877798 [details]
Bug 1353064 - Add-on always prints at 100% due to missing nsPrintSettingsX::GetScaling() impl

https://reviewboard.mozilla.org/r/149218/#review156560

::: widget/cocoa/nsPrintSettingsX.mm:318
(Diff revision 2)
>  NS_IMETHODIMP
> +nsPrintSettingsX::GetScaling(double *aScaling)
> +{
> +  NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT;
> +
> +  NSMutableDictionary* printInfoDict = [mPrintInfo dictionary];

How about use NSDictionary type instead of NSMutableDictonary?
I think that mutable dictinary is awful in getter.

	Hiroshi Hatake [:cosmo0920]
	Comment 19 • 7 years ago

Haik, any update on this?
Above review comment is just mutability dictionary type issue.
Otherwise, it is fine for me.

	Haik Aftandilian [:haik] Assignee
	Comment 20 • 7 years ago

(In reply to Hiroshi Hatake [:cosmo0920] from comment #19)
> Haik, any update on this?
> Above review comment is just mutability dictionary type issue.
> Otherwise, it is fine for me.

Thanks for the feedback, Hiroshi. I got sidetracked with my sandboxing work. I'll post an update to the code and we can get this landed in 56.

	Hiroshi Hatake [:cosmo0920]
	Comment 22 • 7 years ago
mozreview-review

Comment on attachment 8877798 [details]
Bug 1353064 - Add-on always prints at 100% due to missing nsPrintSettingsX::GetScaling() impl

https://reviewboard.mozilla.org/r/149218/#review163910

	Pulsebot
	Comment 23 • 7 years ago

Pushed by haftandilian@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5a4f7cc99805
Add-on always prints at 100% due to missing nsPrintSettingsX::GetScaling() impl r=cosmo0920

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 24 • 7 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/5a4f7cc99805

	Loic
	Comment 25 • 7 years ago

dw-dev, could you verify it's fixed in the next Nightly, please?

	dw-dev Reporter
	Comment 26 • 7 years ago

Loic, This bug was reported to me by a user of Print Edit.  I do not have access to an up-to-date Mac OS X system, so I have never actually reproduced this bug myself.  Therefore, I am unable to confirm whether scaling works as expected with the new build.  I could try contacting the user who reported the problem to me, but at that time the user was on the current release (Firefox 52), not Nightly.

	Bogdan Maris, Desktop QA
	Comment 27 • 7 years ago

I've been able to reproduce the initial issue using firefox 52beta9 on macOS 10.12.6 and verified that the scale works properly on Firefox 56 beta 11 using the same platform (macOS 10.12.6).