Issues were occuring where a process swap would be decided upon during
on-examine-response, but before the swap could be handled by the
channel, the channel was redirected.
This new code takes the mildly hacky approach of simply using a separate
observer notification which is fired at the correct time. A better
solution may be to use a dedicated service for responding to these
events, however that was not implemented for this initial patch.
Depends on D18606
Differential Revision: https://phabricator.services.mozilla.com/D19691
--HG--
extra : moz-landing-system : lando
Issues were occuring where a process swap would be decided upon during
on-examine-response, but before the swap could be handled by the
channel, the channel was redirected.
This new code takes the mildly hacky approach of simply using a separate
observer notification which is fired at the correct time. A better
solution may be to use a dedicated service for responding to these
events, however that was not implemented for this initial patch.
Depends on D18607
Differential Revision: https://phabricator.services.mozilla.com/D19691
--HG--
extra : source : 3d24e8e81c02af9d1edec7571afecefb0d2f1eb4
Issues were occuring where a process swap would be decided upon during
on-examine-response, but before the swap could be handled by the
channel, the channel was redirected.
This new code takes the mildly hacky approach of simply using a separate
observer notification which is fired at the correct time. A better
solution may be to use a dedicated service for responding to these
events, however that was not implemented for this initial patch.
Depends on D18607
Differential Revision: https://phabricator.services.mozilla.com/D19691
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
This patch essentially creates a separate, static component database for
statically-defined CID and contract ID entries, and gives it precedence over
the runtime DB. It combines the two separate databases by updating existing
code to use lookup functions which understand both databases, and then access
all entries through wrappers which defer to the appropriate underlying type.
Static component entries require no runtime relocations, and require no
writable data allocation aside from one pointer-sized BSS entry per CID, and
one bit of BSS per contract ID.
To achieve this, all strings in the static lookup tables are stored as indexes
into a static string table, all constructor functions live in a switch
statement which compiles to a relative jump table, and all writable data for
static entries is accessed by indexed lookups into BSS arrays.
We also avoid creating nsIFactory entries for static components when possible
by adding a CreateInstance method to nsFactoryEntry and the corresponding
entry wrapper to directly call the appropriate constructor method, and only
create a factory object when required by external code.
Differential Revision: https://phabricator.services.mozilla.com/D15035
--HG--
extra : rebase_source : 903a6f31c6290d0090e6765e0e317d1f749c5855
extra : source : b8d2dfdfc324c53ce5aacc822ce52d4e2bfdc31a
This patch essentially creates a separate, static component database for
statically-defined CID and contract ID entries, and gives it precedence over
the runtime DB. It combines the two separate databases by updating existing
code to use lookup functions which understand both databases, and then access
all entries through wrappers which defer to the appropriate underlying type.
Static component entries require no runtime relocations, and require no
writable data allocation aside from one pointer-sized BSS entry per CID, and
one bit of BSS per contract ID.
To achieve this, all strings in the static lookup tables are stored as indexes
into a static string table, all constructor functions live in a switch
statement which compiles to a relative jump table, and all writable data for
static entries is accessed by indexed lookups into BSS arrays.
We also avoid creating nsIFactory entries for static components when possible
by adding a CreateInstance method to nsFactoryEntry and the corresponding
entry wrapper to directly call the appropriate constructor method, and only
create a factory object when required by external code.
Differential Revision: https://phabricator.services.mozilla.com/D15035
--HG--
extra : rebase_source : 8d02ff3b67b8078d1ac837d8c12f54786155c6b6
extra : absorb_source : 0fe36ca220c9270e634abf5b1f320a01878e0ce7
extra : histedit_source : 51521ceae2c1b3e4e8bf63d4ed1e2e67e9468780
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
With the old process selector service implementation, non-cached loads
would skip the call into the process selector.
This implementation piggybacks atop the existing 'redirectTo' mechanism.
This is unfortunately not the perfect system for catching these loads,
as it doesn't provide an opportunity for performing a final process
switch before redirecting to a non-http channel. In addition, it doesn't
provide indication that a redirect is going to happen, causing
potentially unnecessary process switches.
Not all places where 'redirectTo' is supported use this mechanism. This
process switching mechanism is only checked in situations after
http-on-examine-response.
Potential future changes include:
1. Moving these checks closer to the real 'OnStartRequest' call (e.g.
in ContinueProcessNormal + ContinueOnStartRequest3). This would mean
that loads other than the final load will not cause process swaps.
2. Adding a callback before a redirect is performed, passing in the new
channel, and allowing modifications to be made. This would allow
performing a process swap before redirecting to a non-http(s)
channel.
Depends on D15609
Differential Revision: https://phabricator.services.mozilla.com/D15610
--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
1. This patch somehow sets a "breakpoint" in ProcessPartialContent() and ProcessNotModified() to really stop doing things after ProcessPartialContent() and ProcessNotModified(), when the channel is suspended.
2. Add a test for this.
Differential Revision: https://phabricator.services.mozilla.com/D13277
--HG--
extra : moz-landing-system : lando
Test steps:
1. Register the observers for http-on-modify-request and http-on-before-connect.
2. There are 3 cases to be tested.
- suspend in http-on-modify-request
- suspend in http-on-before-connect
- suspend in both observers
3. See if the channel can be resumed correctly.
Differential Revision: https://phabricator.services.mozilla.com/D11899
--HG--
extra : moz-landing-system : lando
This adds a way to simulate failed network connections, allowing the addition of test coverage that would otherwise not be available. This is used in the Downloads tests to ensure that failures at the network level are handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D15522
--HG--
extra : rebase_source : 2597b27de5213b0322520cefafe10a197d0d3b83
The test intermittently fails on OSX. For some reason start(PORT) doesn't always fail when PORT is in use, so we timeout because the handler is never called. I suspect it's because of how SO_REUSEADDR and SO_REUSEPORT are handled on sockets sever-side on OSX. Since httpd is used for unit tests, there is little risk in disabling the test on OSX.
The alternative is to check for a timeout, and in that case switch to another port - which is cumbersome, and not the purpose of the test.
Differential Revision: https://phabricator.services.mozilla.com/D14756
--HG--
extra : moz-landing-system : lando
In mozTXTToHTMLConv, FindURL is not able to correctly calculate replaceBefore for nested email addresses/URLs such as john@doe.org}john@doe.org. As a workaround, we keep track of the end of the last URL HTML markup in the output string and skip any subsequent URLs whose replaceBefore would cut into this markup.
Depends on D13645
Differential Revision: https://phabricator.services.mozilla.com/D13646
--HG--
extra : moz-landing-system : lando
In mozTXTToHTMLConv, FindURL is not able to correctly calculate replaceBefore for nested email addresses/URLs such as john@doe.org}john@doe.org. As a workaround, we keep track of the end of the last URL HTML markup in the output string and skip any subsequent URLs whose replaceBefore would cut into this markup.
Differential Revision: https://phabricator.services.mozilla.com/D13391
--HG--
extra : moz-landing-system : lando
* Moves the value of the pref and also the fallback definition in nsTextToSubURI.cpp to a separate file.
* The file has better formatting, so we may follow its history more easily. Each range of consecutive values is defined on a separate line.
* Renames `blacklist` to `blocklist` for pref and variable names (for this individual pref. network.IDN.whitelist.* needs to be handled in a separate bug)
* Changes nsIDNService::mIDNBlocklist from being an nsString to sorted nsTArray<char16> and uses mozilla::BinarySearch() to check for characters.
Differential Revision: https://phabricator.services.mozilla.com/D12209
--HG--
extra : moz-landing-system : lando
This moves the check for a non-http proxy from the socket transport callbacks in
nsHttpConnection to nsHttpChannel before the connection occurs.
MozReview-Commit-ID: CJIozDInXWz
This is likely not the best approach to detecting IP connectivity.
The check has a slight delay until the failure counter reaches the threshold.
A more reliable way will be added in a follow-up.
Depends on D7844
Differential Revision: https://phabricator.services.mozilla.com/D8704
--HG--
extra : moz-landing-system : lando
Sometimes nsIBinaryInputStream.readByteArray could return NS_BASE_STREAM_WOULD_BLOCK.
In this case we want to retry reading from the input stream.
Differential Revision: https://phabricator.services.mozilla.com/D9900
--HG--
extra : moz-landing-system : lando
This is likely not the best approach to detecting IP connectivity.
The check has a slight delay until the failure counter reaches the threshold.
A more reliable way will be added in a follow-up.
Depends on D7844
Differential Revision: https://phabricator.services.mozilla.com/D8704
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
The test ocasionally fails out in e10s mode, because stream.available() might not return the entire string length (it's async). So the child process needs to wait for all of the bytes to be read.
Differential Revision: https://phabricator.services.mozilla.com/D9274
--HG--
extra : moz-landing-system : lando
By setting network.dns.native-is-localhost in this test, it makes all native
name resolves use "localhost" and thus avoids causing an assert if this test
runs with TRR enabled and network.trr.uri set to point to an actual external
host name.
MozReview-Commit-ID: D1df6VtfckR
Differential Revision: https://phabricator.services.mozilla.com/D9070
--HG--
extra : moz-landing-system : lando
In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server.
To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry.
Depends on D8071
Differential Revision: https://phabricator.services.mozilla.com/D8072
--HG--
extra : rebase_source : 43d92c631b964c52b551a700b0954276e91695d6
extra : source : 7f9d03c29a6ffd82c1b5e17c14e27a2ae9d64434
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : rebase_source : eb4961f05a52e557e7d2d986d59e0a2cf18a3447
extra : source : dd1c31ea78c2b15d14750d137037a54d50719997
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server.
To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry.
Depends on D8071
Differential Revision: https://phabricator.services.mozilla.com/D8072
--HG--
extra : moz-landing-system : lando
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
The templated version of Finalize is not needed, because the argument
being passed in is already an nsIURI, so the QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6862
--HG--
extra : moz-landing-system : lando
Necko does not allow for a CONNECT only request to happen. This adds a flag
to signal an http channel should only CONNECT if proxied. This flag can only be
set if an HTTPUpgrade handler has been assigned. As proposed by rfc7639, an
alpn header will be included in the CONNECT request. Its value is determined by
the upgrade protocol passed to HTTPUpgrade.
The flag is added as part of nsIHttpChannelInternal because it is dependent on
HTTPUpgrade. It exists as a capability flag since the channel's transaction
needs to know to complete after a successful CONNECT. Also the transaction's
connection needs to know to stop writing transaction data after it CONNECTs or
if there's no proxy, and to not tell the transaction to reset.
If an nsHttpChannel has this flag set then the upgrade handler will receive the
socket after the CONNECT succeeds without doing tls if https.
In order to support xpcshell-test for this change, nsHttpConnectionMgr does a
little check to see if HTTPUpgrade callback is in JavaScript. If it is then
the callback is invoked on the main thread.
--HG--
extra : rebase_source : 96cdfe0e1ffe2f7dad7d12c83c22be92d118195a
extra : intermediate-source : 70710e9bf3d98488485c3265ebdea09683a42a80
extra : source : 25b4b531c10c4b2dae416fd7d744a63a32fed7e5
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
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
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
We've introduced a new pref network.cookie.quotaPerHost and also a rule that the value of network.cookie.maxPerHost should always be bigger than network.cookie.quotaPerHost. So, before changing the value of network.cookie.maxPerHost, we have to set network.cookie.quotaPerHost first.
This patch only sets network.cookie.quotaPerHost equal to network.cookie.maxPerHost - 1 in all failed tests.
Differential Revision: https://phabricator.services.mozilla.com/D4346
--HG--
extra : moz-landing-system : lando
Previously (under TLS 1.2), we would avoid advertising h2 support if the
spec-mandatory suite was disabled. That suite is only required for TLS
1.2, though. We would like to offer h2 in more cases, so only check for
the mandatory suite if someone has turned off TLS 1.3.
Differential Revision: https://phabricator.services.mozilla.com/D4345
--HG--
extra : moz-landing-system : lando
As initially implemented, nsITLSServerSocket by default enabled the use of the
TLS session cache provided by NSS. However, no consumers of nsITLSServerSocket
actually used it. Because it was an option, though, PSM had to jump through some
hoops to a) make it work in the first place and b) not have NSS panic on
shutdown. Furthermore, it meant increased memory usage for every user of Firefox
(and again, nothing actually used the feature, so this was for naught).
In bug 1479918, we discovered that if PSM shut down before Necko, NSS could
attempt to acquire a lock on the session cache that had been deleted, causing a
shutdown hang. We probably should make it less easy to make this mistake in NSS,
but in the meantime bug 1479918 needs uplifting and this workaround is the
safest, most straight-forward way to achieve this.
Differential Revision: https://phabricator.services.mozilla.com/D3919
--HG--
extra : moz-landing-system : lando
This patch adds simple stubs to convert between the nsISimpleEnumerator
iteration protocol and the JS iteration protocol.
Each iterable object is required to have an @@iterator method which returns an
object implementing the iterator protocol. The later objects, by convention,
also have such a method which returns the object itself.
This patch adds both a @@iterator() and entries() methods to
nsISimpleEnumerator. The former returns an iterator which returns plain
nsISupports objects. The latter accepts an IID and queries each element to
that IID before returning it. If any element fails to query, the error is
propagated to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D3727
--HG--
extra : rebase_source : 340eb43a1c5e6d7ae69fa8ee486d66d31d079b14
extra : histedit_source : f3efc6c265851a563968ee410e4626e0540f55c0
The mIsTrackingResource flag on nsIHttpChannel was split into two separate
flags depending on whether or not the resource is third-party. The correct
flag will be set by the channel classifier. Similarly, a new function was
introduced, GetIsThirdPartyTrackingResource(), for those consumers (like TP)
who only care about third-party trackers.
The existing function, GetIsTracking(), will continue to look at both
first-party and third-party trackers (the behavior since first party
tracking was added to annotations in bug 1476324).
The OverrideTrackingResource() function now allows nsHTMLDocument to
override both mIsFirstPartyTrackingResource and
mIsThirdPartyTrackingResource, but since this function is a little dangerous
and only has a single user, I added an assert to make future callers think
twice about using it to opt out of tracking annotations.
Currently, only the default storage restrictions need to look at first-party
trackers so every other consumer has been moved to
mIsThirdPartyTrackingResource or GetIsThirdPartyTrackingResource().
This effectively reverts the third-party checks added in bug 1476715 and
replaces them with the more complicated check that was added in bug 1108017.
It follows the approach that Ehsan initially suggested in bug 1476715. It
also reverts the changes in the expected values of the tracking annotation
test since these were, in hindsight, a warning about this regression.
Depends on D3722
Differential Revision: https://phabricator.services.mozilla.com/D3723
--HG--
extra : moz-landing-system : lando
A new parameter is introduced to makeConnection in order to specify
the topWindowURI. This will be useful in future tests, but it also
highlights the fact that we do set this in all of the existing
tests.
Finally, I also added a number of comments and explicit parameter
setting in order to make the test more readily understandable.
Depends on D3720
Differential Revision: https://phabricator.services.mozilla.com/D3721
--HG--
extra : moz-landing-system : lando
Set the "network.trr.disable-ECS" pref to false to disable.
MozReview-Commit-ID: GE6L8Vpvuu0
Differential Revision: https://phabricator.services.mozilla.com/D2933
--HG--
extra : moz-landing-system : lando
Test steps:
1. Create a XHR
2. Initializes the XHR with non-ascii username and password
3. Send the request to server
4. Check if the server receives the correct Authorization header
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
The patch introduces NS_GetURIWithNewRef and NS_GetURIWithNewRef which perform the same function.
Differential Revision: https://phabricator.services.mozilla.com/D2239
--HG--
extra : moz-landing-system : lando
This delays the creation of the PAC thread until we need to dispatch a
runnable to it.
--HG--
extra : rebase_source : 8897d3d8724f082ad33027635795512ccb4a17eb
extra : source : 068bb4e7b8494d8ae82dfd1b1f22680234bf038c
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.
Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
looked for a PAC file at http://wpad/wpad.dat
This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.
The high-level components of this patch are:
* nsIDHCPClient.idl - this is an interface which has been defined for querying the
DHCP server.
* nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
thread. The class ExecutePACThreadAction has been augmented to include an
instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
file) back to the nsPACMan object.
* nsProtocolProxyService.cpp
Minor changes to reflect the fact that the PAC URL not being set does not always
mean there is no PAC to be used; instead it could be in the process of being
detected.
* TestPACMan.cpp
This is a new file, and tests only the DHCP auto-detect functionality.
Some tests use multiple threads, as they test the non-blocking proxy detection.
* DHCPUtils.cpp
A class containing the main logic for querying DHCP.
* WindowsNetworkFunctionsWrapper.cpp
A very thin wrapper around the Windows API calls needed by DHCPUtils.
This class was introduced so it could be mocked out in tests.
* nsWindowsDHCPClient.cpp
* An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
most logic is implemented in DHCPUtils.
* TestDHCPUtils.cpp
Tests for DHCPUtils and nsWindowsDHCPClient
MozReview-Commit-ID: 4xFQz3tOLEx
--HG--
extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.
Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
looked for a PAC file at http://wpad/wpad.dat
This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.
The high-level components of this patch are:
* nsIDHCPClient.idl - this is an interface which has been defined for querying the
DHCP server.
* nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
thread. The class ExecutePACThreadAction has been augmented to include an
instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
file) back to the nsPACMan object.
* nsProtocolProxyService.cpp
Minor changes to reflect the fact that the PAC URL not being set does not always
mean there is no PAC to be used; instead it could be in the process of being
detected.
* TestPACMan.cpp
This is a new file, and tests only the DHCP auto-detect functionality.
Some tests use multiple threads, as they test the non-blocking proxy detection.
* DHCPUtils.cpp
A class containing the main logic for querying DHCP.
* WindowsNetworkFunctionsWrapper.cpp
A very thin wrapper around the Windows API calls needed by DHCPUtils.
This class was introduced so it could be mocked out in tests.
* nsWindowsDHCPClient.cpp
* An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
most logic is implemented in DHCPUtils.
* TestDHCPUtils.cpp
Tests for DHCPUtils and nsWindowsDHCPClient
MozReview-Commit-ID: 4xFQz3tOLEx
--HG--
extra : rebase_source : 4fb364432625418acf743b67a2caadc5a92caf7c
Changes:
- The API now returns a Promise containing a sequence of IOActivityData dictionnaries.
- All the code related to notifications and XPCOM is removed.
- The counters are no longer reset to 0 when the API is called
MozReview-Commit-ID: 7J2EgFqDgf
--HG--
extra : rebase_source : eb7dc3e0921b12bbb3715a90863dc8e2a60c1c09
Changes:
- The API now returns a Promise containing a sequence of IOActivityData dictionnaries.
- All the code related to notifications and XPCOM is removed.
- The counters are no longer reset to 0 when the API is called
MozReview-Commit-ID: 7J2EgFqDgf
--HG--
extra : rebase_source : 4e16640a3f52fd7c042687471153971a66158623
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : e473a7b0ec7c231ab321846c5ddcc4d6a88d7245
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : 0a92195b6b8314383c63de4b2bb1dfe033c40e9f
This change makes nsEscape::T_EscapeURL not escape spaces when passed esc_OnlyNonASCII.
This fixes a web-compat issue for URLs such as "javascript: alert('hello');" and the fact that data: URIs with spaces around MIME type are rejected.
MozReview-Commit-ID: 91Qw9foW6Y3
--HG--
extra : rebase_source : 2da1b5f305ca2abcce2f9988cd6a5cbc12635c61
This change makes nsEscape::T_EscapeURL not escape spaces when passed esc_OnlyNonASCII.
This fixes a web-compat issue for URLs such as "javascript: alert('hello');" and the fact that data: URIs with spaces around MIME type are rejected.
MozReview-Commit-ID: B78AacLxGBp
--HG--
extra : rebase_source : fcef25fab58f7da1732725054ae684588f2e0e89
Generalizes NetworkActivity so it can be used for sockets but also disk files.
The host/port data becomes a single location string prefixed with socket://
or file:// and we're not using the FD as the identifier anymore.
IOActivityMonitor is now used in three places:
- nsFileStreams for plain files
- TelemetryVFS for sqlite files
- nsSocketTransport & nsUDPSocket for UDP & TCP sockets
MozReview-Commit-ID: GNu5o400PaV
--HG--
rename : netwerk/base/NetworkActivityMonitor.cpp => netwerk/base/IOActivityMonitor.cpp
rename : netwerk/base/NetworkActivityMonitor.h => netwerk/base/IOActivityMonitor.h
rename : netwerk/base/nsINetworkActivityData.idl => netwerk/base/nsIIOActivityData.idl
extra : rebase_source : 55a1c51b261ffbe16f88671d55445d1b0d9106b6
We were erroneously looking for the first reasonably-valued
server-timing-param for each name. However, that's not how it works. We
should really be looking for the first server-timing-param regardless
of how reasonable its value is.
MozReview-Commit-ID: LwaHFyCpteU
--HG--
extra : rebase_source : 995f14fec3bd130e6eeada6c4cac0db0b27e618f
Make sure cookies aren't saved on channel headers in the content process.
Adds test to verify that this works, and removes tests that expected cookie headers to be visible to the child.
MozReview-Commit-ID: KOB83xpuAlF
--HG--
extra : rebase_source : 6f9a5ef570fb23200acf8d75285e67d80b7c27f0
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
... and before chasing a cname, check if the address record for that
CNAME is actually in fact already provided in the DNS packet that passed
on the CNAME!
Some existing tests ajusted for this. Two new tests added.
MozReview-Commit-ID: CBMO7N7jMEX
--HG--
extra : rebase_source : 1110a8df6d89fcbb0ad2a35b3762b837ce7a1e18
