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
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
nsIPrintingPromptService comes from an era when the platform print code would
open the print settings dialog, which defaulted to the OS native dialogs.
Its purpose was to allow that dialog to be overridden by embedders to provide
their own interface for the user to select print settings. Nowadays the
platform print code does not open the dialogs. Instead apps like Firefox are
responsible for getting the print settings to pass to the platform code, and
the platform code provides a way to open the OS native print dialog if they
want to use that (nsIPrintDialogService). So nsIPrintingPromptService no longer
has any purpose, and just adds indirection and needless complexity.
Differential Revision: https://phabricator.services.mozilla.com/D146232
Having the called-back-for-new-static-doc logic mixed in with the
start-new-print logic was confusing. The new structure, function names
and comments should hopefully make it easier for people unfamiliar with the
various printing code flows to understand and reason about this code. It also
allows the addition of new print-via-system-dialog logic without things getting
completely out of hand.
Differential Revision: https://phabricator.services.mozilla.com/D135451
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
We don't "pass" print settings to the content process by saving them to prefs,
so the test is no longer useful (this removes the code it's testing anyway).
Differential Revision: https://phabricator.services.mozilla.com/D135349
Printing was failing for silent window.print() printing because we need a
RemotePrintJobChild. The content process side of the print now asks the parent
process to send a valid nsIPrintSettings object and a RemotePrintJobChild
before it starts printing.
Printing was also failing for silent print-to-file printing in the case that
the user omits to set the `printer.print_to_filename` pref. That was because
we weren't setting a fallback value for nsIPrintSettings.toFileName.
Differential Revision: https://phabricator.services.mozilla.com/D134799
Printing was failing for silent window.print() printing because we need a
RemotePrintJobChild. The content process side of the print now asks the parent
process to send a valid nsIPrintSettings object and a RemotePrintJobChild
before it starts printing.
Printing was also failing for silent print-to-file printing in the case that
the user omits to set the `printer.print_to_filename` pref. That was because
we weren't setting a fallback value for nsIPrintSettings.toFileName.
Differential Revision: https://phabricator.services.mozilla.com/D134799
We need to be displayed when cloning into a same-process frame, so that
the preview code hooks up to the view tree correctly and the frame is
correctly painted.
This works for out-of-process frames, but mostly by chance.
Fortify the printPreview() API code to gracefully handle that case, and
remove the sessionrestore special-case which is not really special.
Differential Revision: https://phabricator.services.mozilla.com/D119980
We were using the top BrowsingContextGroup id in this case, which is
obviously wrong. Also make the API take a BrowsingContext directly,
rather than passing outerwindowids around.
Differential Revision: https://phabricator.services.mozilla.com/D112413
This makes it trivial to choose the right BrowserParent to print a
browsing context, by removing the OuterWindowID / FrameLoader
indirections.
Differential Revision: https://phabricator.services.mozilla.com/D112412
Selection may be null if the page got hidden in e.g., the afterprint
event listener or somewhere else.
Add a try catch for good measure, assuming there's no selection is
always safe.
I'll try to get an automated test-case for this working, though it might
be tricky.
Depends on D109714
Differential Revision: https://phabricator.services.mozilla.com/D109715
Ensure we report the error to the web console, and that the print
browser gets removed, as that is what will exit the modal state in the
page that's printing.
Differential Revision: https://phabricator.services.mozilla.com/D109714
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
Uses a new printing actor to determine if there was a selection within
the browsing context.
We now create two browsers, the primary browser and a selected browser,
and will use the appropriate browser depending on the settings value
for printSelectionOnly.
Differential Revision: https://phabricator.services.mozilla.com/D94467
