This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
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
The main point of this change is to not use TYPE_OTHER in `TryCacheLoadAndCompileScript()`,
for extra clarity, we're not using a catch-all TYPE_INTERNAL_SCRIPT.
This is why the changeset introduces a new type TYPE_INTERNAL_FRAME_MESSAGEMANAGER_SCRIPT
which in itself adds lots of changes to various files.
Differential Revision: https://phabricator.services.mozilla.com/D85977
On Linux PID_MAX_LIMIT is 2^22. By default pid_max was set to 2^15, but
systemd since version 243 sets it to 2^22.
nsHttpHandler::NewChannelId uses PID shifted by 32 bits to generate
channelId, and that results in values greater than 2^53.
Such values are fine for uint64_t, but when we pass channelId to
devtools it gets converted to JavaScript floats, and values greater
than 2^53 get errors in lower two bits. This in turn leads to much
sorrow, like request id collisions or "no headers for this request".
This patch shifts the PID by one bit less, resulting in channelIds
that always fit into safe JavaScript integer range for all PIDs.
Differential Revision: https://phabricator.services.mozilla.com/D85990
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
6.5 A ServiceMode RR is considered "compatible" with a client if the
client implements support for all its mandatory keys. If the SVCB
RRSet contains no compatible RRs, the client will generally act as if
the RRSet is empty.
Differential Revision: https://phabricator.services.mozilla.com/D85838
Christoph Kerschbaumer
Bogdan Tara
Valentin Gosu
Dragana Damjanovic
Dimi Lee
undef1nd
Brindusan Cristian
Tarek Ziadé
Michael Hoffmann
Dan Glastonbury
Razvan Maries
ffxbld
Kershaw Chang
Frederik Braun
Simon Giesecke
Andy Grover
Cosmin Sabou
Csoregi Natalia
Honza Bambas
Edgar Chen
Platon Pronko
Butkovits Atila
ssengupta
Anny Gakhokidze