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
See the comment.
https://phabricator.services.mozilla.com/D90808 made it so that we
reused the print document (and thus <browser>) to do the actual print
job.
When a print job finishes, we call window.close(), which is used as a
signal to the front-end to clean up the <browser> element. Before that
patch we sent that signal to the browser created in printUtils.js, but
afterwards we send it to the preview window which causes this badness
when the event bubbles up.
Ignoring it effectively restores the previous behavior, so let's do it.
Differential Revision: https://phabricator.services.mozilla.com/D93499
In order to avoid over/under-counting, we need to treat window.print()
specially. The new UI was using aOpenWindowInfo.isForPrintPreview for
that, but that doesn't quite work for the old UI (because it will
trigger a regular print, not a preview).
But since isForPrintPreview was only really needed to distinguish
window.print(), just rename it and set it to true when the old UI is
triggered by window.print() as well.
Differential Revision: https://phabricator.services.mozilla.com/D92925
This allows to use the feature from the context menu and is very
straight-forward.
This has the benefit of working with fission (as print from the focused
frame) and so on.
Making a checkbox on the UI on top of this is doable, but it is a lot
more complex (requires a bunch of both front-end and platform work)
because undoing this implies restoring the DOM which "print selection"
removes.
I think the context menu entry is very useful regardless of whether we
add a checkbox to undo it, and other browsers (with smaller context
menus) seem to agree.
Differential Revision: https://phabricator.services.mozilla.com/D92205
