This avoids exposing printer names to potentially compromised content processes.
The changes in bug 1770211 mean that we no longer create platform specific
nsIDeviceContextSpec instances in the content process, so we no longer need
the printer name to instantiate an nsDeviceContextSpecWin there.
Differential Revision: https://phabricator.services.mozilla.com/D146868
This avoids exposing the path to potentially compromised content processes.
The roundtripping of the toFileName value from RemotePrintJobParent's
mPrintSettings to the content process and then back to
RemotePrintJobParent::InitializePrintDevice was silly anyway.
Differential Revision: https://phabricator.services.mozilla.com/D146867
Lately nsIPrintSession was only used to pass around RemotePrintJobChild objects.
Now that we pass those objects explicitly where needed (part 1), this class
serves no purpose.
Another reason to want to get rid of this class is that having it as a member
of nsIPrintSettings made no sense and was confusing.
Differential Revision: https://phabricator.services.mozilla.com/D146381
nsIPrintSettings is supposed to be a collection of settings passed to the
platform code to determine how the document prints. The
isPrintSelectionRBEnabled member doesn't belong here since it is a flag that
is passed to the OS native print settings dialog to tell it whether to
display a "Print selection only" radio button.
Depends on D146232
Differential Revision: https://phabricator.services.mozilla.com/D146251
This per-printer "print_resolution" about:config pref (which ends up in
nsPrintSettings 'mResolution' member-var) is never exposed in UI, and it's
almost entirely unused. For the usages that do exist (usages of
nsPrintSettings::mResolution), we potentially do the wrong thing when the value
comes from an about:config pref, as described in this bug. These usages scale
the printed output *as if we're printing to a printer with the given
resolution*, though of course we have no guarantee of this being the printer's
actual resolution, when this value comes from about:config prefs.
After this patch, nsPrintSettings will simply use the value that we actually
get from the printer, instead of this potentially-bogus value from
about:config. This will avoid the scaling issues described in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D146261
nsIPrintSettings is supposed to be a collection of settings passed to the
platform code to determine how the document prints. The
isPrintSelectionRBEnabled member doesn't belong here since it is a flag that
is passed to the OS native print settings dialog to tell it whether to
display a "Print selection only" radio button.
Differential Revision: https://phabricator.services.mozilla.com/D146251
nsIPrintSettings.isCancelled was only being set to true by the Windows widget
code ShowNativePrintDialog nowadays. That seems pointless since that widget
code is only invoked under the _showPrintDialog call in print.js, and in the
case that the widget code throws, the print is never invoked and the
nsIPrintSettings object isn't used.
nsIPrintSettings.saveOnCancel was set in some places but never read.
Differential Revision: https://phabricator.services.mozilla.com/D144830
Bug 1757395 basically removed the reason for PPrinting to exist. What remained
essentially just added an unnecessary layer of complexity/indirection to the
creation of PRmotePrintJob actors.
Differential Revision: https://phabricator.services.mozilla.com/D143330
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
This means that more precise values can be stored, so that they match what we
actually retrieve from the printer and use in layout.
Depends on D99806
Differential Revision: https://phabricator.services.mozilla.com/D99807
This patch ensures that the global print_to_filename pref is checked
when initializing print settings from prefs.
It also fixes a regression which was preventing the Linux system dialog
from correctly reading its printer-specific print_to_filename prefs.
Differential Revision: https://phabricator.services.mozilla.com/D98975
... which is an array of pairs of ranges, and use it instead of the
existing printRange / startPage / endPage settings.
Differential Revision: https://phabricator.services.mozilla.com/D96093
Rather than wrapping an NSPrintInfo in nsPrintSettingsX, where we then have two
(potentially conflicting) sources of truth about various settings, we treat the
settings in the base nsPrintInfo class as authoritative, and just apply them to
a temporary NSPrintInfo when needed to interact with platform APIs.
Differential Revision: https://phabricator.services.mozilla.com/D92966
This was the last flag that the PrintOptions bitfield was tracking.
So, this patch is effectively converting that bitfield (and its alias
"PrintOptionsBits") into a new, simpler boolean field named
"isPrintSelectionRBEnabled".
Differential Revision: https://phabricator.services.mozilla.com/D92542
This code looked like it might work, but it seems to have only ever been backed
by per-printer about:config prefs. I believe we only ever exposed UI for this
feature on Linux, via the native GTK dialog; and even there, the UI doesn't
actually seem to have done anything -- it was never wired up to the actual
implementation of even/odd page-skipping.
Differential Revision: https://phabricator.services.mozilla.com/D92528
So that:
* It accounts for @page.
* It is correctly serialized and deserialized over IPC.
* It's nicer to use.
Depends on D92004
Differential Revision: https://phabricator.services.mozilla.com/D92005
I don't see any reason why this shouldn't work off-hand, there's no
gtk globals or such that fundamentally avoid sharing settings.
The PSPrinters stuff is gone so it's not needed to mess up with PS/CUPS
names.
The last used printer name stuff is now just a pref read, so there
shouldn't be sandbox violation shenanigans...
There are some restrictions on what can be set or what not (like, if you
set the paper name that may also override the paper size).
But these are problems that we have when restoring from prefs already,
so there's no reason we shouldn't do this, afaict.
Differential Revision: https://phabricator.services.mozilla.com/D90418