Instead of imposing the min-width as a max-size, make prefwidth act as
it should (as suggesting a preferred width, but with min-content as a
minimum).
This can be reproduced locally by applying a patch like:
```
diff --git a/toolkit/profile/content/profileSelection.xhtml b/toolkit/profile/content/profileSelection.xhtml
index 3dd1c864f79f1..7e8cbf8ce8c3e 100644
--- a/toolkit/profile/content/profileSelection.xhtml
+++ b/toolkit/profile/content/profileSelection.xhtml
@@ -17,7 +17,7 @@
data-l10n-id="profile-selection-window"
orient="vertical"
prefwidth="min-width"
- style="min-width: 30em;"
+ style="min-width: 10em;"
onload="startup();">
<dialog id="profileWindow"
buttons="accept,cancel"
```
Before patch, stuff overflowed. This patch guarantees that everything is
on-screen.
Differential Revision: https://phabricator.services.mozilla.com/D161229
Instead of imposing the min-width as a max-size, make prefwidth act as
it should (as suggesting a preferred width, but with min-content as a
minimum).
This can be reproduced locally by applying a patch like:
```
diff --git a/toolkit/profile/content/profileSelection.xhtml b/toolkit/profile/content/profileSelection.xhtml
index 3dd1c864f79f1..7e8cbf8ce8c3e 100644
--- a/toolkit/profile/content/profileSelection.xhtml
+++ b/toolkit/profile/content/profileSelection.xhtml
@@ -17,7 +17,7 @@
data-l10n-id="profile-selection-window"
orient="vertical"
prefwidth="min-width"
- style="min-width: 30em;"
+ style="min-width: 10em;"
onload="startup();">
<dialog id="profileWindow"
buttons="accept,cancel"
```
Before patch, stuff overflowed. This patch guarantees that everything is
on-screen.
Differential Revision: https://phabricator.services.mozilla.com/D161229
Given how nsIPrintSettings is passed around, stored and copied all over the
place, it's very hard to reason about where and when a RemotePrintJobChild is
needed or valid. This patch avoids all that by explicitly passing a
RemotePrintJobChild when it's needed.
Another reason to make this change is because RemotePrintJobChild really does
not belong on nsIPrintSettings. That interface is supposed to represent a
collection of settings for laying out the document that is to be printed.
Differential Revision: https://phabricator.services.mozilla.com/D146380
These APIs are entirely unused (aside from one usage in a test, which part 1 in
this patch series removed), so this patch shouldn't impact behavior at all.
Historical note: we briefly removed these APIs once before, in this commit:
https://hg.mozilla.org/mozilla-central/rev/c216ff19d690
...but we brought them back because we had a motivating use case at the time.
We don't have any such motivating use cases any more, though. So, this patch
here is essentially a modernized version of that older commit.
Differential Revision: https://phabricator.services.mozilla.com/D108148
We keep mMedium in nsPresContext rather than just looking it up in the
browsing context because that's used quite more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D103782
This was only being checked on OnDonePrinting() which isn't called in
the original docshell. Move it to the window because we don't need to
care about document viewers getting closed during print operations,
they're top level browsers that don't run script.
Differential Revision: https://phabricator.services.mozilla.com/D91416
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
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
Additionally, this patch makes `nsDocumentViewer` which is the only
implementation of `nsIContentViewer` use `mozilla::PresShell` directly
rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D27470
