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
This function (and helper functions that wrap it) will be used extensively
throughout layout code, so keeping it in APZCCallbackHelper seems awkward.
nsLayoutUtils would also be a reasonable place but has the downside that
adding a new function to it triggers recompiling the world.
Differential Revision: https://phabricator.services.mozilla.com/D68296
This function (and helper functions that wrap it) will be used extensively
throughout layout code, so keeping it in APZCCallbackHelper seems awkward.
nsLayoutUtils would also be a reasonable place but has the downside that
adding a new function to it triggers recompiling the world.
Differential Revision: https://phabricator.services.mozilla.com/D68296
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
This code is used to determine the sizes of the top-level windows. However the
code doesn't cause quite desirable behavior (see the bug, and comment 15).
This patch does two things:
* Unifies the html / xul code-paths. This shouldn't change behavior (because
GetXULMinSize returns the fixed min-* property if present anyways), but
makes the patch a bit simpler.
* Makes the min-width of the XUL window be the pref size instead of the
min-size (for the cases where you have no explicit min-width). This looks a
bit counter intuitive, but it's the only way to guarantee that the content
will be shown. This matches the sizing algorithm that dialogs use by default
(via calling window.sizeToContent()), while allowing to undersize the window
via a fixed min-width property.
This in turn makes sizeToContent() work "by default" on XUL windows, avoiding
having to make JS listen to everything that possibly could change the layout of
the document (like resolution changes).
Differential Revision: https://phabricator.services.mozilla.com/D70209
If we get a sub-pixel content size, rounding down may actually cause the content
to wrap, which is not desirable and would cause the content to be truncated.
Differential Revision: https://phabricator.services.mozilla.com/D69744
This fixes the case where you have a focused input (or selection for <input
disabled>) in an <iframe> and move the focus outside of the iframe.
Differential Revision: https://phabricator.services.mozilla.com/D67596
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
