These callers should likely also function with <object> and <embed> loads, so
switching them to GetLoadingBrowsingContext() should be correct.
Differential Revision: https://phabricator.services.mozilla.com/D86583
With these changes, there are still a number of test failures when remote
object/embed is enabled, due to svg sizing and resource timing tests. In order
to land these changes before those features are fixed, it will be placed behind
a pref.
Differential Revision: https://phabricator.services.mozilla.com/D86582
By passing a weak reference back to the DocumentChannelParent into
DocumentLoadListener for object loads, we are able to handle process switching
loads by asking the content process to create a BrowsingContext, and delaying
the real process switch until it becomes available.
The load then completes as it would before, acting as a normal process-switching
subframe load.
Differential Revision: https://phabricator.services.mozilla.com/D86580
There is the same information exposed in DocShellLoadStateInit.
And we don't really need to query user action from BrowsingContext, this
information would be carried in `nsDocShellLoadState`.
Depends on D86724
Differential Revision: https://phabricator.services.mozilla.com/D86773
Starting a load from a link click, to a link with the 'download' attribute
doesn't cancel any existing loads (since it's known to be just a download, not a
navigation, so doesn't need to replace the existing one). But then we have two
DocumentChannels alive at the same time, on the same loadgroup, the loadgroup
copies flags from the old one to the download one, since they're different, and
triggers the assert about setting LoadFlags.
The download one shouldn't really be added to the loadgroup; the progress of the
download should NOT block the 'load' event of the existing navigation.
Differential Revision: https://phabricator.services.mozilla.com/D85964
In process selection logic, ensure that we don't use the original URI for
about:blank and instead use the result principal. If the about:blank load has a
null principal, then revert to using the original URI.
Also, remove an extra about:blank load when an nsFrameLoaderOwner is changing
remoteness to prevent races.
Differential Revision: https://phabricator.services.mozilla.com/D85081
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
This patch uses IPDL's return feature to ensure that the memory
reporter manager won't wait for a report from a child process
that has already exited.
This fixes a memory reporter hang that can happen if a child process
exits during a memory report, when the parent half of the actor is
being held alive. (If the parent half of the actor is not being held
alive, then mMemoryReportRequest will be naturally cleared when it
goes away.)
This was happening frequently on Windows Fission AWSY because that test
does a minimize memory right before it attempts to get a memory report,
and the preallocated content process exits when it sees a message to
minimize memory.
Differential Revision: https://phabricator.services.mozilla.com/D85499
The next patch converts the memory reporting architecture to use the "returns"
feature of IPDL, and mozilla::ipc::RejectCallback does not have a return
type, so this patch removes the return value.
FinishReportingCallback::Callback() needs to remain an XPCOM method
that returns NS_OK because it is called from JS during testing.
Differential Revision: https://phabricator.services.mozilla.com/D85498
Pass internal content policy type to DLL and switch behavior depending on type
being loaded. This implementation immediately redirects channel back to the
content process for further handling.
Depends on D80406
Differential Revision: https://phabricator.services.mozilla.com/D80407
LoadInfo has a number of constructors intended to be used in different contexts.
Add named factory functions to make it clearer in which context the returns
LoadInfo is being used.
Depends on D80404
Differential Revision: https://phabricator.services.mozilla.com/D80405
With these changes, on my Linux analysis with ClangBuildAnalyzer, the
top two expensive headers, DOMTypes.h and TabMessageUtils.h are no longer
among the 30 most expensive headers.
Differential Revision: https://phabricator.services.mozilla.com/D82935
Pass internal content policy type to DLL and switch behavior depending on type
being loaded. This implementation immediately redirects channel back to the
content process for further handling.
Differential Revision: https://phabricator.services.mozilla.com/D80407
LoadInfo has a number of constructors intended to be used in different contexts.
Add named factory functions to make it clearer in which context the returns
LoadInfo is being used.
Differential Revision: https://phabricator.services.mozilla.com/D80405
Nika Layzell
Edgar Chen
Olli Pettay
Csoregi Natalia
Christoph Kerschbaumer
Dan Glastonbury
Razvan Maries
Bogdan Tara
Butkovits Atila
Anny Gakhokidze
Andrew McCreight
Andreas Farre
Jean-Yves Avenard
Sebastian Streich
owlishDeveloper
Peter Van der Beken
Simon Giesecke
Frederik Braun
Narcis Beleuzu
Matt Woodrow
Kershaw Chang