This shouldn't generally happen, but seems it can under some circumstances and
even though I've fixed the error condition that triggers this a null-check here is harmless.
Differential Revision: https://phabricator.services.mozilla.com/D89453
Before bug 1636728 this couldn't happen because print documents weren't
hosted in an <browser>. The presentation of documents that are being
printed should be managed by the print job.
We should, in fact, probably just make mDocument->IsStaticDocument() the
condition, or such.
Differential Revision: https://phabricator.services.mozilla.com/D88901
Other engines also do this, but with my previous patch breaks it
(because we only hit print() on the print-content-viewer _after_ doing
the clone).
So move it before triggering all the machinery, and only for
window.print(). Given we didn't check this for print preview etc, I
think it's fine to carry on for user-triggered loads.
Trivial test-case (which I'm not quite sure how to turn into an
automated test...)
<!doctype html>
<h1>I do get printed but...</h1>
<script>
window.print();
</script>
<h2>Do I?</h2>
Note that this is broken with the new print preview UI already, this
fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D87898
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
This is backed by an existing nsPageSequenceFrame API, which this patch also
renames to use the word "Raw" for consistency across the full callstack.
Differential Revision: https://phabricator.services.mozilla.com/D87886
This change consists of;
1) Use switch statement for the given PrintPreview Navigation type.
2) Simply iterate over the children of nsPageSequenceFrame for
PRINTPREVIEW_GOTO_PAGENUM
3) Use GetCurrentSheetFrameAndPageNumber for PRINTPREVIEW_PREV_PAGE and
PRINTPREVIEW_NEXT_PAGE so that it should now match
printPreviewCurrentPageNumber
(that means the edge case where the current scroll position is in
the gap between pages has been fixed by this change)
4) Scroll to the position where the target frame is positioned at the center of
the print preview scroll port in the cases of PRINTPREVIEW_PREV_PAGE,
PRINTPREVIEW_NEXT_PAGE and PRINTPREVIEW_GOTO_PAGENUM
4) is a bit debatable but it can be now easily modified by changing
ComputeScrollPositionFrameAtCenter later if it turns out the current way is not
reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D87548
So that we can keep using the logic in the old print preview UI.
For the new print preview UI, the original PrintPreviewScrollToPage will be
modified gradually in subsequent changes.
Differential Revision: https://phabricator.services.mozilla.com/D87543
Unfortunately there is no particular way to write automated tests without
exposing a bunch of metrics in the print preview window, such as each
PrintedSheetFrame height, the gap length between the sheets, print preview
scale, the scroll port rect, the current scroll position, etc. etc. So I just
tested this change with the frontend change to show the current page number
there by :mstriemer. [1]
[1] https://phabricator.services.mozilla.com/D86427
Differential Revision: https://phabricator.services.mozilla.com/D87203
This code was there to prevent stuff like bug 424377, but nowadays clone
documents are data documents to begin with, so they can't load scripts.
Differential Revision: https://phabricator.services.mozilla.com/D86948
This is going to be useful for the new print preview UI, which is in a
doorhanger and thus much more likely to be less than the page size.
We (ab)use the existing print preview scaling mechanism. We only need it
after reflowing all pages, so this works.
This whole scaling mechanism is all-in-all not amazing, but the patch is
less gross than I initially thought. It's nice, actually.
We could put the new behavior behind a pref trivially, if that's wanted,
but I honestly thing this behavior is better even without the doorhanger
ui.
Differential Revision: https://phabricator.services.mozilla.com/D83309
The fallback code in nsPrintJob::DoCommonPrint to create an nsIPrintSettings if
none is passed in is never used, since all callers pass a settings object.
However, to simplify future changes I'd like nsGlobalWindowOuter::PrintOuter to
stop creating and passing in its own default valued nsIPrintSettings object.
This patch makes the fallback code that DoCommonPrint calls do what
nsGlobalWindowOuter::PrintOuter does, and makes the latter stop passing in a
settings object.
This patch also removes nsIWebBrowserPrint.globalPrintSettings since
nsGlobalWindowOuter::PrintOuter was its only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D83268
The fallback code in nsPrintJob::DoCommonPrint to create an nsIPrintSettings if
none is passed in is never used, since all callers pass a settings object.
However, to simplify future changes I'd like nsGlobalWindowOuter::PrintOuter to
stop creating and passing in its own default valued nsIPrintSettings object.
This patch makes the fallback code that DoCommonPrint calls do what
nsGlobalWindowOuter::PrintOuter does, and makes the latter stop passing in a
settings object.
This patch also removes nsIWebBrowserPrint.globalPrintSettings since
nsGlobalWindowOuter::PrintOuter was its only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D83268
This fixes two issue.
First, the code shouldn't be dispatching these events every time it gets a new
Print or PrintPreview call. It only needs to dispatch the events to the
original document that we're going to clone from. When cloning from existing
static clones any changes made by 'beforeprint' will be present in the existing
static clone.
Second, the code tries to delay the 'afterprint' event until after
mozPrintCallback callbacks have been invoked, but those callbacks are invoked
in the cloned document, whereas the events are sent to the original document!
So there is no reason to do this.
Differential Revision: https://phabricator.services.mozilla.com/D34280
This fixes two issue.
First, the code shouldn't be dispatching these events every time it gets a new
Print or PrintPreview call. It only needs to dispatch the events to the
original document that we're going to clone from. When cloning from existing
static clones any changes made by 'beforeprint' will be present in the existing
static clone.
Second, the code tries to delay the 'afterprint' event until after
mozPrintCallback callbacks have been invoked, but those callbacks are invoked
in the cloned document, whereas the events are sent to the original document!
So there is no reason to do this.
Differential Revision: https://phabricator.services.mozilla.com/D34280
The first page's content viewer is only saved in the bfcache when the second
page is painted. This can happen after the load event is fired, and in that
scenario, attempting to go back to the first page will reload it rather than
restore it from the bfcache. So for the test to work properly it needs to
wait until the second page is actually painted before it attempts go back.
Differential Revision: https://phabricator.services.mozilla.com/D79347
The probes collect counts for:
- print preview open, and exit without print
- print dialog opened from print preview, and cancelled
- print dialog opened without print preview, and cancelled
- silent prints
- print target
- PDF file
- XPS file
- other (probably print to physical printer, but we can never be sure)
There is some overlap with the existing PRINT_* probes, but I think we should
keep those in place temporarily until we confirm that the new probes produce
numbers that are consistent with the old probes.
This patch only adds 'print target' probes for Windows and macOS.
I use nsDeviceContextSpec*::Init() to collect the 'print target' telemetry
because the way we initialize settings from prefs (and the way macOS works in
particular) make it difficult to reliably determine the target type earlier in
the print process for all possible entry points into the printing code.
Differential Revision: https://phabricator.services.mozilla.com/D78033
