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
This also updates the behavior of the allowDuplicates check:
Instead of only checking if the top dialog is a duplicate, it will now check the whole stack and
skip the dialog open if a duplicate URL is found.
This fixes an issue where callers could alternate between dialogs to bypass the check.
Differential Revision: https://phabricator.services.mozilla.com/D88422
If print.tab_modal.enabled is enabled, we should not display the print preview
menu item, as this will redirect us to the print preview automatically and thus
be redundant with the other print button. We also want to hide the page setup
menu item.
Differential Revision: https://phabricator.services.mozilla.com/D88224
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
* New PrintSettingSelect element for the margin and color-mode picker
* The destination-picker and color-mode picker now extend the PrintSettingSelect
* Drive-by change to have numCopies info use the PrintSettingNumber for consistency & code reuse
* Margin presets are retrieved from a defaultSettings object which is the settings for the current printer without the user pref values
Differential Revision: https://phabricator.services.mozilla.com/D86849
