Closed Bug 1257791 Opened 8 years ago Closed 8 years ago

Printing to PDF using Cairo on Windows fails with blank page.

Categories

(Core :: Printing: Output, defect)

46 Branch
All
Windows
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
firefox46 --- verified
firefox47 --- verified
firefox48 --- verified

People

(Reporter: bobowen, Assigned: bobowen)

References

Details

(Keywords: regression)

Attachments

(1 file)

I broke this when I refactored the DPI and printing scale setting into the nsDeviceContextSpec.

I'd incorrectly thought that an nsDeviceContextSpecWin meant a surface type of gfxSurfaceType::Win32 or gfxSurfaceType::Win32Printing, but it can be gfxSurfaceType::PDF as well.

This PDF functionality on Windows is not actually used by Firefox itself as far as I know, but it is used by at least one addon - Print Edit.
I've not triggered too many jobs here as the Windows test queue is huge and I think very few tests actually hit this code.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f06cb5ca36da
I also noticed that printerName is being leaked in nsDeviceContextSpecWin::Init, but I filed bug 1257841 for that as I'm going to want to uplift this to Beta.
Attachment #8732152 - Flags: review?(jmathies)
Keywords: regression
Comment on attachment 8732152 [details] [diff] [review]
Return correct DPI and printing scale from nsDeviceContextSpecWin when printing to PDF

Review of attachment 8732152 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/windows/nsDeviceContextSpecWin.cpp
@@ +275,5 @@
>  
>  float
> +nsDeviceContextSpecWin::GetDPI()
> +{
> +  return mOutputFormat == nsIPrintSettings::kOutputFormatPDF ? 72.0f : 144.0f;

comment me please

@@ +284,5 @@
>  {
>    MOZ_ASSERT(mPrintSettings);
>  
> +  if (mOutputFormat == nsIPrintSettings::kOutputFormatPDF) {
> +    return 1.0f;

ditto
Attachment #8732152 - Flags: review?(jmathies) → review+
https://hg.mozilla.org/mozilla-central/rev/7a5de08942ca
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Comment on attachment 8732152 [details] [diff] [review]
Return correct DPI and printing scale from nsDeviceContextSpecWin when printing to PDF

Approval Request Comment
[Feature/regressing bug #]:
Bug 1156742.

[User impact if declined]:
Addons (in particular Print Edit) that use the print to PDF functionality on Windows won't work.

[Describe test coverage new/current, TreeHerder]:
There is no automated testing for printing, but this has been tested manually with the Print Edit addon.

[Risks and why]: 
Low - simple change that restores the previous settings for printing to PDF of Windows.

[String/UUID change made/needed]:
Non
Attachment #8732152 - Flags: approval-mozilla-beta?
Attachment #8732152 - Flags: approval-mozilla-aurora?
Comment on attachment 8732152 [details] [diff] [review]
Return correct DPI and printing scale from nsDeviceContextSpecWin when printing to PDF

Potentially important issue, taking it.
Should be in 46 beta 5
Attachment #8732152 - Flags: approval-mozilla-beta?
Attachment #8732152 - Flags: approval-mozilla-beta+
Attachment #8732152 - Flags: approval-mozilla-aurora?
Attachment #8732152 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
Verified as fixed on Windows 10x64 using the Print Edit add-on on the following branches:
* Latest 48.0a1 Nightly, build ID 20160413030239,
* Latest 47.0a2 Aurora, build ID 20160413004016,
* Firefox 46.0b10, build ID 20160411042519.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.