Currently only same origin requests are preloaded and preloads in the
secure context. This may change in the future to match W3C decisions and
Chromes behavior.
Also only images get preloaded. This will change in the future to cover
asset types.
Currently the anchor isn't parsed correctly yet[1], so this will be
fixed in a future patch.
On non-2xx responses of the main document all ongoing preloads get
canceled. Already completed preloads don't get affected and are in the
cache.
It is currently untested whether unused preloads don't have side effects.
Another future patch should cover adding the preload to the devtools.
[1]: https://datatracker.ietf.org/doc/html/rfc8288#section-3.2
Differential Revision: https://phabricator.services.mozilla.com/D137885
Currently only same origin requests are preloaded and preloads in the
secure context. This may change in the future to match W3C decisions and
Chromes behavior.
Also only images get preloaded. This will change in the future to cover
asset types.
Currently the anchor isn't parsed correctly yet[1], so this will be
fixed in a future patch.
On non-2xx responses of the main document all ongoing preloads get
canceled. Already completed preloads don't get affected and are in the
cache.
It is currently untested whether unused preloads don't have side effects.
Another future patch should cover adding the preload to the devtools.
[1]: https://datatracker.ietf.org/doc/html/rfc8288#section-3.2
Differential Revision: https://phabricator.services.mozilla.com/D137885
This clarifies some of the members and arguments which were used in
DocumentLoadListener to make them more clear, adding documentation.
In addition to the simplifications of logic and improved naming, this
patch also moves the responsibility of managing StreamFilterRequest out
of DisconnectListeners so that stream listeners behave more
consistently, as the existing flag doesn't map well to whether or not
they should be cleared.
This was kept seperate from part 1 as it is largely a clarity
improvement, and may make it harder to see the important changes in that
part.
Depends on D143676
Differential Revision: https://phabricator.services.mozilla.com/D144747
This patch changes how we handle document loads which are being handled
internally but have Content-Disposition: attachment specified at the
DocumentLoadListener layer. This was done as process switching is
currently the only place during a load where we can change the target
BrowsingContext which the load will complete in.
The only situation where we should currently continue to deliver a
successful request to the default content-viewer despite
Content-Disposition: attachment being specified is when we choose to
handle a downloaded PDF internally, so this shouldn't impact other
cases.
The change is handled by forcing a process switch under the hood, and
opening a new browser window asynchronously to handle the process
switch, similar to how object and embed load upgrades are handled. This
is done using nsIBrowserDOMWindow to attempt to respect the user's
window opening preferences.
A small change to browser.js was also made to try to encourage the new
tab to be opened next to the previous tab, as well as to avoid starting
unnecessary new processes when creating the new browser window.
Differential Revision: https://phabricator.services.mozilla.com/D143675
If we enable pref browser.tabs.documentchannel.parent-controlled and remove the
requirement for needing SHIP for parent-initiated loads, test
NavigationDelegateTest#redirectIntentLoad times out. It times out because when
redirecting in Document Channel, we were using the URI of the redirect that
failed.
Differential Revision: https://phabricator.services.mozilla.com/D132093
In Bug 1644914 code was added that assumed all UI code for loading URIs goes
through only one path - nsDocShell::LoadURI. Since we are enabling parent
controlled loads now, we need to make sure that we set the same flag in this
code path too.
Differential Revision: https://phabricator.services.mozilla.com/D130198
EH_TIME_TO_FINAL_RESPONSE - This will collect time duration between receiving a 103 response and the final response. This is only collected for 2xx response and only if at least one 103 has been received.
EH_NUM_OF_HINTS_PER_PAGE - number of 103 responses received for a page load. 0 will mean that a page has not received a 103 response. This is only collected for 2xx response.
EH_FINAL_RESPONSE - whether the final response was 2xx or any other code. This is only collected if at least one 103 has been received.
The change also introduced the class EarlyHintsPreloader that will be extended to perform all EarlyHints tasks.
Differential Revision: https://phabricator.services.mozilla.com/D132556
EH_TIME_TO_FINAL_RESPONSE - This will collect time duration between receiving a 103 response and the final response. This is only collected for 2xx response and only if at least one 103 has been received.
EH_NUM_OF_HINTS_PER_PAGE - number of 103 responses received for a page load. 0 will mean that a page has not received a 103 response. This is only collected for 2xx response.
EH_FINAL_RESPONSE - whether the final response was 2xx or any other code. This is only collected if at least one 103 has been received.
The change also introduced the class EarlyHintsPreloader that will be extended to perform all EarlyHints tasks.
Differential Revision: https://phabricator.services.mozilla.com/D132556
EH_TIME_TO_FINAL_RESPONSE - This will collect time duration between receiving a 103 response and the final response. This is only collected for 2xx response and only if at least one 103 has been received.
EH_NUM_OF_HINTS_PER_PAGE - number of 103 responses received for a page load. 0 will mean that a page has not received a 103 response. This is only collected for 2xx response.
EH_FINAL_RESPONSE - whether the final response was 2xx or any other code. This is only collected if at least one 103 has been received.
The change also introduced the class EarlyHintsPreloader that will be extended to perform all EarlyHints tasks.
Differential Revision: https://phabricator.services.mozilla.com/D132556
EH_TIME_TO_FINAL_RESPONSE - This will collect time duration between receiving a 103 response and the final response. This is only collected for 2xx response and only if at least one 103 has been received.
EH_NUM_OF_HINTS_PER_PAGE - number of 103 responses received for a page load. 0 will mean that a page has not received a 103 response. This is only collected for 2xx response.
EH_FINAL_RESPONSE - whether the final response was 2xx or any other code. This is only collected if at least one 103 has been received.
The change also introduced the class EarlyHintsPreloader that will be extended to perform all EarlyHints tasks.
Differential Revision: https://phabricator.services.mozilla.com/D132556
In Bug 1644914 code was added that assumed all UI code for loading URIs goes
through only one path - nsDocShell::LoadURI. Since we are enabling parent
controlled loads now, we need to make sure that we set the same flag in this
code path too.
Differential Revision: https://phabricator.services.mozilla.com/D130198
In Bug 1644914 code was added that assumed all UI code for loading URIs goes
through only one path - nsDocShell::LoadURI. Since we are enabling parent
controlled loads now, we need to make sure that we set the same flag in this
code path too.
Differential Revision: https://phabricator.services.mozilla.com/D130198
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
There are races which are more common after these patches where an implicit
about:blank load races with a speculative parent process load's process switch.
In this situation, bad behaviour can result as we process a navigation started
by a process which we process-switched away from. By tracking the explicit
ContentParent which is making the DocumentLoadListener request, we can catch
situations like this and avoid navigations being started from the wrong
processes.
Differential Revision: https://phabricator.services.mozilla.com/D120672
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
There are races which are more common after these patches where an implicit
about:blank load races with a speculative parent process load's process switch.
In this situation, bad behaviour can result as we process a navigation started
by a process which we process-switched away from. By tracking the explicit
ContentParent which is making the DocumentLoadListener request, we can catch
situations like this and avoid navigations being started from the wrong
processes.
Differential Revision: https://phabricator.services.mozilla.com/D120672
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
There are races which are more common after these patches where an implicit
about:blank load races with a speculative parent process load's process switch.
In this situation, bad behaviour can result as we process a navigation started
by a process which we process-switched away from. By tracking the explicit
ContentParent which is making the DocumentLoadListener request, we can catch
situations like this and avoid navigations being started from the wrong
processes.
Differential Revision: https://phabricator.services.mozilla.com/D120672
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
There are races which are more common after these patches where an implicit
about:blank load races with a speculative parent process load's process switch.
In this situation, bad behaviour can result as we process a navigation started
by a process which we process-switched away from. By tracking the explicit
ContentParent which is making the DocumentLoadListener request, we can catch
situations like this and avoid navigations being started from the wrong
processes.
Differential Revision: https://phabricator.services.mozilla.com/D120672
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
There are races which are more common after these patches where an implicit
about:blank load races with a speculative parent process load's process switch.
In this situation, bad behaviour can result as we process a navigation started
by a process which we process-switched away from. By tracking the explicit
ContentParent which is making the DocumentLoadListener request, we can catch
situations like this and avoid navigations being started from the wrong
processes.
Differential Revision: https://phabricator.services.mozilla.com/D120672
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671