After the previous patches, nsViewManager is basically a backpointer to
its pres shell.
Remove it and just make PresShell manage the root view directly. After
this is done, we can decide what to do about nsView (which is itself
little more than a widget listener that forwards to pres shell right
now).
This technically starts listening to mParentWidget slightly later (on
pres shell creation), but I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D272890
This patch does not change behavior (other than a minor correctness fix in some
off-by-default logging; see below).
As shown in the removed line of the init list, this mFrameType member-var's
semantics are equivalent to a null-check of the mParent member-var. So: rather
than encoding that same information twice, this patch simplifies to just
directly null-check the mParent pointer at all the usage sites.
Before this patch, nsPrintJob.cpp had two different patterns for logging
mFrameType; sometimes with a global `gFrameTypesStr` array, and other times
with a local `types` array (with shorter 2-character strings). I've converted
both of these to helper-functions.
In the case of the `types` array, the old code used a 4-value array, which was
interesting since the enum type only had 2 possible values. This discrepancy is
just due to an oversight in bug 1769508, where we recently condensed the enum
from 4 values to 2; that bug technically should've condensed these arrays as
well (but didn't do so). This left these arrays' enum-to-string mapping being
wrong (since eIFrame changed its numeric value from 2 to 1 in bug 1769508), but
probably nobody has used this logging code in a while, so nobody
noticed. Anyway: in this patch, I'm restoring the mappings that we had before
that change (so we'll log "DC" for root print objects and "IF" for non-root
i.e. iframe-flavored print objects).
Differential Revision: https://phabricator.services.mozilla.com/D150177
Move two assignments to the declaration site, and remove an unnecessary
nullptr assignment (for a nsCOMPtr which is nullptr by default).
Depends on D150079
Differential Revision: https://phabricator.services.mozilla.com/D150176
This patch doesn't change behavior; it's just refactoring.
The pre-existing Init code is now clearly infallible, now that earlier patches
have removed all of Init's NS_ENSURE_STATE arg-null-checks (which were Init's
only failure-returning codepaths).
So: now that it's infallible, we can just merge the Init() code directly into
the constructor.
This lets us promote some member-variables to be 'const' as well, since they
will now be initialized in the init list and are never modified after that.
Differential Revision: https://phabricator.services.mozilla.com/D150079
This patch doesn't change behavior. It just changes to c++ reference types and
code-comments to indicate where we know that pointers have been null-checked
(and removes some null-checks that now become trivially-unnecessary).
I've added code-comments to justify why we know these args are non-null.
Generally, `nsPrintObject::Init`'s args are null-checked by the caller, except
in one case (in `nsPrintJob::DoCommonPrint`) where the Document* pointer in
question was _not_ directly null-checked by the caller. But fortunately, it is
null-checked earlier, higher up in the call-stack. So, this patch simply
propagates the C++ reference type-conversion up to that point for additional
clarity.
Differential Revision: https://phabricator.services.mozilla.com/D150078
This patch doesn't change behavior.
The two init functions were already pretty similar. This patch merges them,
and uses the "aParent" arg as a signal for which variant we're handling (with
the "root" variant being signalled via a null value).
This usage of aParent (to distinguish between variants) is valid, as long as we
can assume that the old `InitAsNestedObject` variant was always guaranteed to
receive a non-null value for its aParent arg. (That would mean that we're OK to
use that arg's nullness as a way to distinguish between the two variants in
their new merged form.)
And indeed, we're safe to make this assumption, since there's only one callsite
for the `InitAsNestedObject` version (which is in
`nsPrintJob::BuildNestedPrintObjects`), and it dereferences the pointer before
calling into this init function. So, the pointer has to be non-null, or else
we would have crashed at the earlier dereference.
Therefore, this conversion (and usage of aParent to distinguish between
variants) is valid.
(Spoiler alert: a later patch in this series will merge this Init() method
into the constructor. I'm doing this as a multi-step process with this
intermediate state, in order to hopefully make it easier to reason about the
conversion and confirm that it's valid.)
Differential Revision: https://phabricator.services.mozilla.com/D150077
The comments and structure of this code no longer made much sense after the
last 20 years of churn, including those made in bug 1659432 and bug 1552785.
Differential Revision: https://phabricator.services.mozilla.com/D146717
The comments and structure of this code no longer made much sense after the
last 20 years of churn, including those made in bug 1659432 and bug 1552785.
Differential Revision: https://phabricator.services.mozilla.com/D146717
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
The COOP header is set to BrowsingContext only in Document::StartDocumentLoad.
If the replaced document has a different COOP header from one in its docshell.
Then, we can crash while creating a window global child for a new inner window.
Differential Revision: https://phabricator.services.mozilla.com/D85127
The COOP header is set to BrowsingContext only in Document::StartDocumentLoad.
If the replaced document has a different COOP header from one in its docshell.
Then, we can crash while creating a window global child for a new inner window.
Differential Revision: https://phabricator.services.mozilla.com/D85127
This also refactors the selection printing code, so that as we build the tree we
record which nsPrintObject should be used if printing a Selection is chosen.
Differential Revision: https://phabricator.services.mozilla.com/D85600
This also refactors the selection printing code, so that as we build the tree we
record which nsPrintObject should be used if printing a Selection is chosen.
Differential Revision: https://phabricator.services.mozilla.com/D85600
nsPrintObject::InitAsNestedObject made sure that all nsPrintObjects were set to
print-as-is except for frameset documents and their sub-documents. (Note the
setting of mParent->mPrintAsIs, which would actually set the root nsPrintObject
to print-as-is if it wasn't a frameset document!).
The SetPrintAsIs() calls in nsPrintJob::EnablePOsForPrinting would then
subsequently also set those frameset and frame nsPrintObjects to be print-as-is
in all but one edge case, namely printing a selection when there isn't a focused
window (which I'm not sure is even be possible).
Differential Revision: https://phabricator.services.mozilla.com/D77621
We nowadays already directly set nsPrintObject->mContent in
nsPrintObject::InitAsNestedObject. This patch adds the setting of mFrameType
and PrintAsIs that MapContentForPO does, making MapContentToWebShells and
MapContentForPO redundant.
Differential Revision: https://phabricator.services.mozilla.com/D77597
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
- Clones selection ranges to the static document for printing
- Static docs can remove selections without referring to original doc
Differential Revision: https://phabricator.services.mozilla.com/D71110
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
This change was causing issues with images not displaying and iframes not
displaying correctly after multiple print preview calls.
Differential Revision: https://phabricator.services.mozilla.com/D44585
This should ensure that the inner window for each document is set up correctly
before iframe elements are created in them during a static clone. Other,
non-static-clone cases are not affected because they cannot load subframes.
Differential Revision: https://phabricator.services.mozilla.com/D38931
Sylvestre Ledru