searching for reviewer(bagder)
a27d4d17da8508fe3afb41ec0e312a14e9d2be57: Bug 1492938 - Attempt compiling PAC scripts as UTF-8 first if they're valid UTF-8, and only if that fails inflate to UTF-16 and compile that. r=bagder
Jeff Walden <jwalden@mit.edu> - Tue, 04 Dec 2018 14:40:45 -0500 - rev 450511
Push 35204 by rmaries@mozilla.com at Fri, 14 Dec 2018 16:23:13 +0000
Bug 1492938 - Attempt compiling PAC scripts as UTF-8 first if they're valid UTF-8, and only if that fails inflate to UTF-16 and compile that. r=bagder
4933066fd34964dab0f7bb04614a8d6baa9d3136: Bug 1492938 - Move PAC script compilation (currently as Latin-1 only) into a lambda for readability. r=bagder
Jeff Walden <jwalden@mit.edu> - Tue, 04 Dec 2018 14:38:46 -0500 - rev 450188
Push 35191 by ccoroiu@mozilla.com at Wed, 12 Dec 2018 05:12:41 +0000
Bug 1492938 - Move PAC script compilation (currently as Latin-1 only) into a lambda for readability. r=bagder
cf97290aeea1015925955b375b220cb16ee77aa4: Bug 1506612 - Check whether the tunnel connection is initiated. r=bagder
Dragana Damjanovic <dd.mozilla@gmail.com> - Fri, 16 Nov 2018 10:42:56 +0000 - rev 446784
Push 35052 by apavel@mozilla.com at Sat, 17 Nov 2018 11:25:40 +0000
Bug 1506612 - Check whether the tunnel connection is initiated. r=bagder Differential Revision: https://phabricator.services.mozilla.com/D12003
7155e69bc42c3613901dd356371e5529bf85e855: Bug 1507139 - Fix h2 push for esni r=bagder
Dragana Damjanovic <dd.mozilla@gmail.com> - Thu, 15 Nov 2018 13:10:54 +0000 - rev 446617
Push 35046 by btara@mozilla.com at Fri, 16 Nov 2018 09:46:36 +0000
Bug 1507139 - Fix h2 push for esni r=bagder Differential Revision: https://phabricator.services.mozilla.com/D11881
d3d642b624886729636c3690a806f38b4d737731: Bug 1505867 - Add pref for hpack table dumps. r=bagder
Nicholas Hurley <hurley@mozilla.com> - Fri, 09 Nov 2018 07:23:17 +0000 - rev 445452
Push 35016 by rmaries@mozilla.com at Fri, 09 Nov 2018 21:48:23 +0000
Bug 1505867 - Add pref for hpack table dumps. r=bagder Now that h2 is pretty well stable, and we're fairly confident in our hpack table implementation, it's worth hiding this logging without some extra hoops, as it's just a lot of noise in logs. Differential Revision: https://phabricator.services.mozilla.com/D11406
634d9ca93c9491c01d901c53418288bc284567d2: Bug 1494364 - don't prune proxy if all non-direct proxies are disabled r=bagder
Junior Hsu <juhsu@mozilla.com> - Mon, 05 Nov 2018 07:12:54 +0000 - rev 444446
Push 34996 by rgurzau@mozilla.com at Tue, 06 Nov 2018 09:53:23 +0000
Bug 1494364 - don't prune proxy if all non-direct proxies are disabled r=bagder Differential Revision: https://phabricator.services.mozilla.com/D10625
73dd4b1d8f333c47b85960c730206e47d46ab007: Bug 1503573 - Disable TFO all together. r=bagder
Dragana Damjanovic <dd.mozilla@gmail.com> - Wed, 31 Oct 2018 14:20:35 +0000 - rev 443753
Push 34969 by cbrindusan@mozilla.com at Wed, 31 Oct 2018 21:39:53 +0000
Bug 1503573 - Disable TFO all together. r=bagder Differential Revision: https://phabricator.services.mozilla.com/D10365
e37e0592161b07d597de68c743a9d146f3650753: Bug 1503247 - Extend TLS_EARLY_DATA_* telemetry probes. r=bagder
Dragana Damjanovic <dd.mozilla@gmail.com> - Wed, 31 Oct 2018 09:24:13 +0000 - rev 443696
Push 34967 by aiakab@mozilla.com at Wed, 31 Oct 2018 16:33:06 +0000
Bug 1503247 - Extend TLS_EARLY_DATA_* telemetry probes. r=bagder Differential Revision: https://phabricator.services.mozilla.com/D10222
23895ff54c060382cc4a4900d9e5b61157beb746: No Bug, mozilla-central repo-update HSTS HPKP remote-settings tld-suffixes - a=repo-update r=bagder,RyanVM
ffxbld <ffxbld@mozilla.com> - Tue, 23 Oct 2018 20:24:21 +0000 - rev 442642
Push 34916 by aiakab@mozilla.com at Wed, 24 Oct 2018 04:14:42 +0000
No Bug, mozilla-central repo-update HSTS HPKP remote-settings tld-suffixes - a=repo-update r=bagder,RyanVM Differential Revision: https://phabricator.services.mozilla.com/D9534
28403444666ca113c31b269dd55d31159ac2fe6b: Bug 1219935 - Skip OCSP request if PAC download is in progress r=keeler,bagder
Kershaw Chang <kershaw@mozilla.com> - Mon, 22 Oct 2018 09:07:51 +0000 - rev 442298
Push 34904 by archaeopteryx@coole-files.de at Mon, 22 Oct 2018 17:25:25 +0000
Bug 1219935 - Skip OCSP request if PAC download is in progress r=keeler,bagder This is a straightforward patch. Just add a new attribute in nsIProtocolProxyService to indicate whether PAC is still loading. If yes, fail the OCSP request. Differential Revision: https://phabricator.services.mozilla.com/D9154
ab0725fa9dc15ce3e3d8c0c15f63df516cdd12cd: Bug 1495024 - Firefox does not use exponential back-off after failing to load a PAC file. r=bagder
Polly Shaw <polly.shaw@gmail.com> - Fri, 19 Oct 2018 09:13:16 +0000 - rev 442124
Push 34890 by dvarga@mozilla.com at Sat, 20 Oct 2018 09:40:11 +0000
Bug 1495024 - Firefox does not use exponential back-off after failing to load a PAC file. r=bagder This patch addresses a bug introduced in the solution to Bug 356831, in which the back-off time for reloading PAC files was set to the shortest interval every time a failure happened, thus auto-detecting PAC every 5 seconds on a network on which WPAD did not resolve when the proxy was set to auto-detect. The changes in this patch are: * nsPACMan.h - declares a private overload to LoadPACFromURI, with an additional parameter called aResetLoadFailureCount. * nsPACMan.cpp - moves the implementation of the old LoadPACFromURI to the new private overload, with the modification that the mLoadFailureCount field is only reset to 0 if aResetLoadFailureCount is true. Replaces the implementation of the public LoadPACFromURI with a call to the private overload with aResetLoadFailureCount = true. Also replaces the call made from within nsPACMan when triggering an internal reload with a call with aResetLoadFailureCount = false, thus ensuring that internally triggered reloads do not reset the back-off time. Differential Revision: https://phabricator.services.mozilla.com/D9035
9e0a42364ef5fd6fd57d06a5df8113d34cb4b7f0: Bug 1499864 - WindowsNetworkFunctionsWrapper's dtor should be virtual. r=bagder
Jeff Gilbert <jgilbert@mozilla.com> - Thu, 18 Oct 2018 08:57:46 +0000 - rev 441985
Push 34884 by csabou@mozilla.com at Fri, 19 Oct 2018 04:16:16 +0000
Bug 1499864 - WindowsNetworkFunctionsWrapper's dtor should be virtual. r=bagder Also delete declaration of an unused var. Both of these are compile warnings on win64 clang-cl. MozReview-Commit-ID: aOBmtxgpz6 Differential Revision: https://phabricator.services.mozilla.com/D9029
a4b43a47589a481f19fd60184881ed5d8caddd73: Bug 1498782 - Skip thread shutdown in nsHostResolver if there are still active threads after a delay r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 17 Oct 2018 06:24:39 +0000 - rev 441632
Push 34870 by ncsoregi@mozilla.com at Wed, 17 Oct 2018 16:53:25 +0000
Bug 1498782 - Skip thread shutdown in nsHostResolver if there are still active threads after a delay r=bagder Differential Revision: https://phabricator.services.mozilla.com/D8725
3f4e7b1382fd2749c9fa7ae950f12e513c356c5b: Bug 1496224 - Followup to 1409570 - fix clang-tidy complaint r=bagder
Nicholas Hurley <hurley@mozilla.com> - Thu, 04 Oct 2018 08:43:54 +0000 - rev 439629
Push 34781 by ncsoregi@mozilla.com at Thu, 04 Oct 2018 22:28:48 +0000
Bug 1496224 - Followup to 1409570 - fix clang-tidy complaint r=bagder Differential Revision: https://phabricator.services.mozilla.com/D7652
cc56daee035f30628eb6b56706ea7b5fb8ede0ff: Bug 1489229 - Return early from WPAD runnable when pref has been changed r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Thu, 04 Oct 2018 08:42:21 +0000 - rev 439538
Push 34778 by nbeleuzu@mozilla.com at Thu, 04 Oct 2018 15:22:02 +0000
Bug 1489229 - Return early from WPAD runnable when pref has been changed r=bagder Bug 356831 added a release assert that when performing WPAD the network.proxy.type pref is always 4 (PROXYCONFIG_WPAD). However, when changing the pref, the runnable is scheduled to run before the PAC thread is shutdown, so it will see the pref that is not PROXYCONFIG_WPAD, while attempting to do WPAD. To avoid this situation, we simply exit early when we detect the wrong pref value. Differential Revision: https://phabricator.services.mozilla.com/D7617
2f9e7263731f258f1d75688ea1e9ee41a352da62: Bug 1409570 - Ensure that transactions matched with http/2 pushed streams are properly finished. r=bagder
Nicholas Hurley <hurley@mozilla.com> - Mon, 01 Oct 2018 21:52:57 +0000 - rev 439067
Push 34752 by cbrindusan@mozilla.com at Tue, 02 Oct 2018 03:59:45 +0000
Bug 1409570 - Ensure that transactions matched with http/2 pushed streams are properly finished. r=bagder There was an earlier fix to this, that fixed part of the issue, but that fix was racy. In the case where the transaction was matched with the pushed stream before the pushed stream received its END_STREAM, and the response headers did not include a content-length, the transaction would never notice that the data was done being sent. When that transaction was necessary for the load event to fire, the page would get stuck in the loading state until the user explicitly cancelled. This new patch ensures that the transaction will notice the EOS by making sure the pushed stream gets inserted into the list of push streams with data in the case described above. (The previous patch, which is still in the tree, is still necessary, but not sufficient, to fix the issue.) Differential Revision: https://phabricator.services.mozilla.com/D7298
ab11bd42e90cfad4327c285b9f02accd8d372b03: Bug 1481251 - Optimize non-A/AAAA type DNS records. r=bagder
Dragana Damjanovic <dd.mozilla@gmail.com> - Thu, 27 Sep 2018 09:28:36 +0000 - rev 438530
Push 34724 by ccoroiu@mozilla.com at Thu, 27 Sep 2018 21:36:09 +0000
Bug 1481251 - Optimize non-A/AAAA type DNS records. r=bagder Split nsHostRecord into AddrHostRecord and TypeHostRecord for standard address dns queries and queries by-type. Differential Revision: https://phabricator.services.mozilla.com/D6130
72d92155fb642884e7295ca9be6923f8f75d30b3: Bug 1481251 - Optimize non-A/AAAA type DNS records. r=bagder
Dragana Damjanovic <dd.mozilla@gmail.com> - Wed, 26 Sep 2018 20:10:30 +0000 - rev 438402
Push 34720 by ebalazs@mozilla.com at Thu, 27 Sep 2018 09:17:07 +0000
Bug 1481251 - Optimize non-A/AAAA type DNS records. r=bagder Split nsHostRecord into AddrHostRecord and TypeHostRecord for standard address dns queries and queries by-type. Differential Revision: https://phabricator.services.mozilla.com/D6130
437dc941487e9b9802a8d756b4b2d2dcf87e2ff7: Bug 1493415 - Re-enable warnings as errors on clang-cl in toolkit/system/windowsDHCPClient/tests/gtest/. r=bagder
Masatoshi Kimura <VYV03354@nifty.ne.jp> - Sat, 22 Sep 2018 20:34:27 +0900 - rev 438041
Push 34708 by ebalazs@mozilla.com at Tue, 25 Sep 2018 09:42:40 +0000
Bug 1493415 - Re-enable warnings as errors on clang-cl in toolkit/system/windowsDHCPClient/tests/gtest/. r=bagder
e414fcdabb7209d3ac6a0052f4c0c8c8c89ab35d: Bug 1488061 - Remove Query/Ref from the directory listing URI r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Tue, 11 Sep 2018 14:33:34 +0300 - rev 435688
Push 34618 by btara@mozilla.com at Tue, 11 Sep 2018 22:13:11 +0000
Bug 1488061 - Remove Query/Ref from the directory listing URI r=bagder
417abd88f3076a9ff086e7c6026991ddae7ef4c6: Bug 1476996 - Implement cross process redirection in Http on the parent process r=bagder,nika
Valentin Gosu <valentin.gosu@gmail.com> - Tue, 04 Sep 2018 20:45:22 +0000 - rev 434708
Push 34576 by ebalazs@mozilla.com at Wed, 05 Sep 2018 09:43:04 +0000
Bug 1476996 - Implement cross process redirection in Http on the parent process r=bagder,nika 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
45605798ecfe97742b9571c04cc151afe5426c19: Bug 1476996 - Implement cross process redirection in Http on the parent process r=bagder,nika
Valentin Gosu <valentin.gosu@gmail.com> - Tue, 04 Sep 2018 16:40:57 +0000 - rev 434597
Push 34572 by btara@mozilla.com at Tue, 04 Sep 2018 22:54:11 +0000
Bug 1476996 - Implement cross process redirection in Http on the parent process r=bagder,nika 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
9de74f5039a47707af05a44381f94c59a3ac39a9: Bug 1478732 - Change nsHostResolver to dispatch one resolver task per native lookup r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Tue, 07 Aug 2018 07:03:57 +0000 - rev 430524
Push 34407 by dvarga@mozilla.com at Wed, 08 Aug 2018 22:00:35 +0000
Bug 1478732 - Change nsHostResolver to dispatch one resolver task per native lookup r=bagder Differential Revision: https://phabricator.services.mozilla.com/D2431
9893cdaed08b246de7c488ca3209b6b2a4b6661e: Bug 1448034 - Part 2: Lazily create ProxyResolution thread. r=bagder
Eric Rahm <erahm@mozilla.com> - Mon, 16 Jul 2018 16:05:39 -0700 - rev 427024
Push 34291 by ebalazs@mozilla.com at Wed, 18 Jul 2018 09:33:54 +0000
Bug 1448034 - Part 2: Lazily create ProxyResolution thread. r=bagder This delays the creation of the PAC thread until we need to dispatch a runnable to it.
bdba0cfc639e6bf4a2a8a7a9297d0cfa80fa04a6: Bug 1448034 - Part 1: Get rid of SysProxySetting threads. r=bagder
Eric Rahm <erahm@mozilla.com> - Tue, 10 Jul 2018 18:02:21 -0700 - rev 427023
Push 34291 by ebalazs@mozilla.com at Wed, 18 Jul 2018 09:33:54 +0000
Bug 1448034 - Part 1: Get rid of SysProxySetting threads. r=bagder
068bb4e7b8494d8ae82dfd1b1f22680234bf038c: Bug 1448034 - Part 2: Lazily create ProxyResolution thread. r=bagder
Eric Rahm <erahm@mozilla.com> - Mon, 16 Jul 2018 16:05:39 -0700 - rev 426890
Push 34289 by toros@mozilla.com at Tue, 17 Jul 2018 21:56:05 +0000
Bug 1448034 - Part 2: Lazily create ProxyResolution thread. r=bagder This delays the creation of the PAC thread until we need to dispatch a runnable to it.
eb542860b989d4f6ea1ffcb29ff843b857d78482: Bug 1448034 - Part 1: Get rid of SysProxySetting threads. r=bagder
Eric Rahm <erahm@mozilla.com> - Tue, 10 Jul 2018 18:02:21 -0700 - rev 426889
Push 34289 by toros@mozilla.com at Tue, 17 Jul 2018 21:56:05 +0000
Bug 1448034 - Part 1: Get rid of SysProxySetting threads. r=bagder
3e47ebfc2f424bb13d55f15cef17c94a82e774a3: Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin
Polly Shaw <polly.shaw@gmail.com> - Thu, 07 Jun 2018 23:07:28 +0100 - rev 426779
Push 34285 by btara@mozilla.com at Mon, 16 Jul 2018 21:58:41 +0000
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin 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
a36553625346a9269e7a345b8b017c9b4fe90a2e: Bug 1467102 - Fix the ftp diversion. r=bagder
Dragana Damjanovic <dd.mozilla@gmail.com> - Wed, 11 Jul 2018 10:01:43 -0400 - rev 426214
Push 34267 by rgurzau@mozilla.com at Wed, 11 Jul 2018 22:05:21 +0000
Bug 1467102 - Fix the ftp diversion. r=bagder
a7a1006e2f522ab6f994e2ae8e67da0f6293c329: Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin
Polly Shaw <polly.shaw@gmail.com> - Thu, 07 Jun 2018 23:07:28 +0100 - rev 425643
Push 34262 by csabou@mozilla.com at Tue, 10 Jul 2018 21:51:50 +0000
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin 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
d7788f2fd8a2d23d5cdd179115b2d7258d6d4f02: Bug 1471280 - Add new pref for how much longer resolver threads should remain idle r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 04 Jul 2018 21:25:28 +0200 - rev 425157
Push 34237 by apavel@mozilla.com at Thu, 05 Jul 2018 16:28:59 +0000
Bug 1471280 - Add new pref for how much longer resolver threads should remain idle r=bagder The new pref is "network.dns.resolver-thread-extra-idle-time-seconds" The default is 60 seconds. This means that threads will stay idle for an extra 60 seconds, after which they are shutdown. Setting the pref to 0 would preserve the behaviour before the threads were swiched to use nsThreadPool - meaning that they would be shutdown immediately after ThreadFunc completes. Setting the pref to -1 would keep the threads alive forever. MozReview-Commit-ID: CoUB5gan4MR
db553cb4218deaae330d6a0692b7a00e22ecc03e: Bug 1471280 - Use nsThreadPool for DNS resolver threads r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 04 Jul 2018 20:36:58 +0200 - rev 425156
Push 34237 by apavel@mozilla.com at Thu, 05 Jul 2018 16:28:59 +0000
Bug 1471280 - Use nsThreadPool for DNS resolver threads r=bagder Instead of creating and deleteing each thread, we use a nsThreadPool with a max of 8 resolver threads. Whereas before each thread would run ThreadFunc exactly once then shut down, the threads may now remain active for a while. During this time we may post another task(runnable) to the thread. MozReview-Commit-ID: FiE370ic1ah
0032f8f594fa6153d98b039515375b71e5bb550a: Bug 1472788 - Use smart pointers in nsHostResolver::Create r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Mon, 02 Jul 2018 21:46:16 +0000 - rev 424780
Push 34224 by shindli@mozilla.com at Tue, 03 Jul 2018 21:55:38 +0000
Bug 1472788 - Use smart pointers in nsHostResolver::Create r=bagder Small patch to test out phabricator Differential Revision: https://phabricator.services.mozilla.com/D1916
59a408f5d9923159f01ba3ff8ccf82dfd03e1a42: Bug 1471628 - Use singleton for captive portal constructor r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Mon, 02 Jul 2018 15:30:33 +0200 - rev 424760
Push 34223 by aiakab@mozilla.com at Tue, 03 Jul 2018 08:56:10 +0000
Bug 1471628 - Use singleton for captive portal constructor r=bagder This is to make sure that the test is using the same Captive Portal Service that nsIOService initializes.
327de25643e2eafc6878bfc1fc39c8ceaa6d490d: Bug 1471628 - Add test for Captive Portal Service r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Mon, 02 Jul 2018 15:26:48 +0200 - rev 424759
Push 34223 by aiakab@mozilla.com at Tue, 03 Jul 2018 08:56:10 +0000
Bug 1471628 - Add test for Captive Portal Service r=bagder
f4de76c196666f2fa6130fa6be4304b8463d368f: Bug 1471628 - Use singleton for captive portal constructor r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 27 Jun 2018 19:44:17 +0200 - rev 424163
Push 34200 by shindli@mozilla.com at Thu, 28 Jun 2018 21:52:47 +0000
Bug 1471628 - Use singleton for captive portal constructor r=bagder This is to make sure that the test is using the same Captive Portal Service that nsIOService initializes. MozReview-Commit-ID: E8iURrsBkdu
eeec72dc70ac6d77405ae0336c118238689b982a: Bug 1471628 - Add test for Captive Portal Service r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 27 Jun 2018 17:19:42 +0200 - rev 424162
Push 34200 by shindli@mozilla.com at Thu, 28 Jun 2018 21:52:47 +0000
Bug 1471628 - Add test for Captive Portal Service r=bagder MozReview-Commit-ID: KgMN90ERTh5
80dd9e57c3a4544ea7c8284efec3f2f6e6e4d1c2: Bug 1426019 - Use nsIThread in nsHostResolver r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Mon, 18 Jun 2018 18:35:16 +0200 - rev 422942
Push 34159 by dluca@mozilla.com at Tue, 19 Jun 2018 21:53:05 +0000
Bug 1426019 - Use nsIThread in nsHostResolver r=bagder MozReview-Commit-ID: LOt7VX9mj7r
cb84b0e19643f215290c367bee8ad63e4c6aef7b: Bug 1417827 - Pass DNS arguments as nsACString& instead of char* r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 15 Jun 2018 01:15:13 +0200 - rev 422607
Push 34139 by aciure@mozilla.com at Fri, 15 Jun 2018 09:48:05 +0000
Bug 1417827 - Pass DNS arguments as nsACString& instead of char* r=bagder MozReview-Commit-ID: 7Zk0wM2wsJF
535a93ad81a1c1d7d81205373b92c49191637f4b: Bug 1417827: Convert internal char* to nsCString in DNS.h r=bagder
Jeff Hemphill <jthemphill@gmail.com> - Wed, 29 Nov 2017 23:30:27 -0800 - rev 422606
Push 34139 by aciure@mozilla.com at Fri, 15 Jun 2018 09:48:05 +0000
Bug 1417827: Convert internal char* to nsCString in DNS.h r=bagder MozReview-Commit-ID: Js1mXiKaKnt
35655153f9c927031e251bfd04c8a2effb51d6ae: Bug 1417827 - Pass DNS arguments as nsACString& instead of char* r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Thu, 14 Jun 2018 14:30:40 +0200 - rev 422571
Push 34139 by aciure@mozilla.com at Fri, 15 Jun 2018 09:48:05 +0000
Bug 1417827 - Pass DNS arguments as nsACString& instead of char* r=bagder MozReview-Commit-ID: GqNYfjy9SFp
9606d0d95b5387f124a3de62fb6475952f566829: Bug 1417827: Convert internal char* to nsCString in DNS.h r=bagder
Jeff Hemphill <jthemphill@gmail.com> - Wed, 29 Nov 2017 23:30:27 -0800 - rev 422570
Push 34139 by aciure@mozilla.com at Fri, 15 Jun 2018 09:48:05 +0000
Bug 1417827: Convert internal char* to nsCString in DNS.h r=bagder MozReview-Commit-ID: Js1mXiKaKnt
190c4f057ffafa28a9abec657a0c70fe8a9489ab: Bug 1417827 - Pass DNS arguments as nsACString& instead of char* r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Thu, 14 Jun 2018 14:30:40 +0200 - rev 422564
Push 34139 by aciure@mozilla.com at Fri, 15 Jun 2018 09:48:05 +0000
Bug 1417827 - Pass DNS arguments as nsACString& instead of char* r=bagder MozReview-Commit-ID: GqNYfjy9SFp
fc388a747aba88d3eb535e6105305bd85914600b: Bug 1417827: Convert internal char* to nsCString in DNS.h r=bagder
Jeff Hemphill <jthemphill@gmail.com> - Wed, 29 Nov 2017 23:30:27 -0800 - rev 422563
Push 34139 by aciure@mozilla.com at Fri, 15 Jun 2018 09:48:05 +0000
Bug 1417827: Convert internal char* to nsCString in DNS.h r=bagder MozReview-Commit-ID: Js1mXiKaKnt
610da3d903bec2983d0e56d051d7d915a6bb86bb: Bug 1462357 - remove the channel and socket interface id r=bagder,baku
Patrick McManus <mcmanus@ducksong.com> - Wed, 16 May 2018 16:05:03 -0400 - rev 419139
Push 34028 by shindli@mozilla.com at Mon, 21 May 2018 21:28:55 +0000
Bug 1462357 - remove the channel and socket interface id r=bagder,baku 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
b18fc4703cbe9dd818419a0561d9a160c5ad6846: Bug 1461182 reduce nsHostRecord overhead by about 40 bytes r=bagder
Patrick McManus <mcmanus@ducksong.com> - Sat, 12 May 2018 14:36:26 -0700 - rev 418143
Push 33994 by nbeleuzu@mozilla.com at Mon, 14 May 2018 21:35:03 +0000
Bug 1461182 reduce nsHostRecord overhead by about 40 bytes r=bagder MozReview-Commit-ID: DvmJE5LcDwQ
204bb43af94351678a0a639bbc0bc7476e91d3aa: Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin
Polly Shaw <polly.shaw@gmail.com> - Sun, 22 Apr 2018 18:13:11 +0100 - rev 415524
Push 33900 by dluca@mozilla.com at Thu, 26 Apr 2018 04:51:04 +0000
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin 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: HinC1UevOon
2a760b1c0759ef67bb3fd7892a8cbac787f0a899: Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin
Polly Shaw <polly.shaw@gmail.com> - Sun, 22 Apr 2018 18:13:11 +0100 - rev 415411
Push 33895 by rgurzau@mozilla.com at Wed, 25 Apr 2018 09:35:01 +0000
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin 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: HinC1UevOon
f7fb95c9979452fe25e42873f54cf56a80a0a0d8: Bug 1452417 - Hold a ref to mRequest in PACResolver::Notify. r=bagder
Valentin Gosu <valentin.gosu@gmail.com> - Tue, 10 Apr 2018 22:07:47 +0200 - rev 413245
Push 33840 by apavel@mozilla.com at Fri, 13 Apr 2018 21:56:54 +0000
Bug 1452417 - Hold a ref to mRequest in PACResolver::Notify. r=bagder MozReview-Commit-ID: 1QeFlAiTCNt
fd4d107aa919f091e3e6e227fe4d6409c6eb1533: Bug 1441327 - Allow for seccomp filtering of socket(AF_INET/AF_INET_6) calls on Linux when using UNIX Domain Sockets for SOCKS Proxy. r=bagder
Richard Pospesel <richard@torproject.org> - Wed, 07 Mar 2018 12:58:00 -0500 - rev 408834
Push 33663 by apavel@mozilla.com at Mon, 19 Mar 2018 22:40:21 +0000
Bug 1441327 - Allow for seccomp filtering of socket(AF_INET/AF_INET_6) calls on Linux when using UNIX Domain Sockets for SOCKS Proxy. r=bagder The initialization path for the SOCKS proxy in firefox involves creating a generic AF_INET socket, and then replacing it if the actual configuration requires something else (either AF_INET6 or AF_LOCAL). With syscall filtering configured to return an error in the event of AF_INET or AF_INET6 socket creation, this initialization path fails. We would like this capability so that we can prevent firefox from making network requests outside of the Tor proxy. This patch adds a check in the initial socket creation path to see if the SOCKS proxy host begins with file:// with the assumption that such URIs point to a UNIX Domain Socket (on Linux+macOS only). In that case, we create an AF_LOCAL socket rather than the requested type. A similar check for Windows already exists to determine if the proxy is actually a named pipe. In the subsequent replacing step no work occurs as the passed in socket matches the type we need, so no changes need to be made there. NOTE: With this change there is still a one-time request for an AF_INET6 socket that occurs. This code path exists to determine whether the system supports IPv6; if socket(AF_INET6...) fails then it is assumed that the system does not. However, this check only affects code that is unreachable when using AF_LOCAL sockets so it seems safe leave as it is. However, this does mean that firefox will still be incompatible with seccomp policies which kill the calling thread in the event of a socket(AF_INET6,...) call.