This lets users e.g. print-to-scale where it matters.
Custom margins are still clamped to unwriteable margins, even when all zeroes,
to avoid impacting user-specified & persisted margins.
Differential Revision: https://phabricator.services.mozilla.com/D152900
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
For smaller paper sizes (e.g. label maker sized paper) it's possible that the defaut margins will be too large, wich results in non-obvious error state for the print dialog. In this case we want to fall back to using "None" margins to ensure the form is valid/printing is still possible.
Differential Revision: https://phabricator.services.mozilla.com/D142889
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
This is important for srcdoc iframes printed from window.print().
Unlike for bug 1710822, there's no awesome way to test this using WPT.
Differential Revision: https://phabricator.services.mozilla.com/D137135
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
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
This test is for the old printing UI, and the equivalent test for the new UI
already exists at toolkit/components/printing/tests/browser_print_simplified_mode.js
Differential Revision: https://phabricator.services.mozilla.com/D133428
This test is for the old printing UI, and the equivalent test for the new UI
already exists at toolkit/components/printing/tests/browser_print_simplified_mode.js
Differential Revision: https://phabricator.services.mozilla.com/D133427
This test checks that the underlying page can navigate and the print preview
document will not start previewing the new underlying document when settings
change. But that's not how the new print UI works. In the new print UI we
cancel the print preview if the document navigates, and we have other tests
for that.
Differential Revision: https://phabricator.services.mozilla.com/D133436
