The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
We nolonger need to use the ContentBlockingAllowListPrincipal in the
channel because we move to check the IsOnContentBlockingAllowList in the
CookieJarSettings when we do a content blocking allow list check. Also,
we would potentially expose the cross-origin info through the
ContentBlockingAllowListPrincipal in the channel. Hence, we will remove
it from the channel.
Differential Revision: https://phabricator.services.mozilla.com/D66214
--HG--
extra : moz-landing-system : lando
DocumentChannel acts as a replacement for HttpChannel where redirects are now entirely handled in the DocumentChannelParent. The ContentChild will receive the final nsIChannel once all redirects have been handled.
Differential Revision: https://phabricator.services.mozilla.com/D37490
***
Removed IPC References in PCContent
***
Removed IPC References on nsContentPermissionHelper
***
Remove IPC Principal from PBrowser
***
Remove IPCPrincipal from the PaymentRequest
***
Remove IPCPrincipal from the PPresentation
***
Remove IPC Principal from PNecko
Differential Revision: https://phabricator.services.mozilla.com/D28650
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
This is needed because early in a content process's lifecycle, NeckoParent may
not have been created yet. This leads to issues when trying to redirect into a
fresh process which hasn't performed network loads yet. By sending the message
over PContent, we can be sure the APIs are available.
Differential Revision: https://phabricator.services.mozilla.com/D15608
--HG--
extra : moz-landing-system : lando
Since we need the loadInfo to set up the IPDL connection, we move the logic to
do so from HttpChannelChild::AsyncOpen to HttpChannelChild::SetLoadInfo
via InitIPCChannel.
It would have been nicer to do so in HttpChannelChild::Init, but
I ran into issues with view-source channels, which required an ugly hack.
Also note that RemoteChannelExists() preserves the existing contract - it is
true between asyncOpen and onStopRequest - but the name is slightly off, as
the channel has already been open by the time we call asyncOpen. We will fix
this in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D12419
--HG--
extra : moz-landing-system : lando
This replaces the tunnel using a new nr_socket implementation. Proxy detection
code is still done in the peer connction. However, the result is only used to
detect a proxy. The result is unused. Address resolution is done by necko code
in the parent process. The new socket wraps a WebrtcProxyChannel which uses
necko to handle proxy negotiation. This has a happy side effect of enabling all
authentication modes that necko already supports for http proxies.
This adds a protocol for Necko to manage, WebrtcProxyChannel. This new protocol
serves as a pipe for a CONNECT tunnel. It is only used in WebRtc and not built
in no WebRtc builds.
--HG--
extra : rebase_source : a951841f95eaaa0562886cf76b405b01f1adf70e
extra : intermediate-source : 5c3da21957fc80b07188bc8a405437b858027a22
extra : source : 594a32883463ab051677ba06e22fa6d062b4b4a9
This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin.
The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test.
How this works:
In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent.
When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel.
A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call.
We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process.
Differential Revision: https://phabricator.services.mozilla.com/D2958
--HG--
rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js
rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs
extra : moz-landing-system : lando
This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin.
The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test.
How this works:
In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent.
When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel.
A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call.
We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process.
Differential Revision: https://phabricator.services.mozilla.com/D2958
--HG--
rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js
rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs
extra : moz-landing-system : lando
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
When writing to alt-data output stream fails for whatever reason, we now try to
truncate alternative data and keep the original data instead of dooming the
whole entry. The patch also changes how is the predicted size passed to the
cache. Instead of a dedicated method it's now an argument of openOutputStream
and openAlternativeOutputStream methods which fail in case the entry would
exceed the allowed limit.
This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
