1. The data sent from `HttpBackgroundChannelParent` to `HttpBackgroundChannelChild` is using type `nsDependentCSubstring`, since I'd like to reduce one copy in parent process.
2. The data sent from `HttpTransactionChild` to `HttpTransactionParent` is using type `nsCString`. The main reason is that the data is actually captured in `HttpTransactionParent::RecvOnDataAvailable` [1] and put in channel event queue. If we use `nsDependentCSubstring` here, the data would be copied in parent process.
3. In `HttpBackgroundChannelChild::RecvOnTransportAndData`, it's inevitable that the data is copied when assigning the data to a `nsCString`, since sometimes `HttpBackgroundChannelChild::RecvOnTransportAndData` needs to be queued and execute later.
[1] https://searchfox.org/mozilla-central/rev/969fc7fa6c3c7fc489f53b7b7f8c902028b5169f/netwerk/protocol/http/HttpTransactionParent.cpp#556
Differential Revision: https://phabricator.services.mozilla.com/D88781
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
Currently the domainLookup time is updated in OnLookupComplete, this
is problematic because since the DNS prefetch is racy, we are unable
to tell if it's a persistent connection, and we don't want to update
domainLookup if it's a persistent connection.
This patch stops updating it in OnLookupComplete to only update
it in OnStopRequest.
Differential Revision: https://phabricator.services.mozilla.com/D88070
This isn't necessary any more, since we now attach StreamFilters directly to the 'real' channel when we replace DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D83594
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
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801