Commit Graph
12 Commits
Author SHA1 Message Date
Mike Hommey bebfc47917 Bug 1839762 - Cast scoped enums to their underlying type when printing them. r=media-playback-reviewers,necko-reviewers,application-update-reviewers,geckoview-reviewers,handyman,emilio,valentin,bytesized,owlish,karlt
There is no implicit conversion for scoped enums, so using them without
an explicit conversion in varargs functions is undefined behavior. GCC
has had a warning about this for a long while, but clang only gained
this a few days ago on trunk.

Differential Revision: https://phabricator.services.mozilla.com/D181723
2023-06-24 20:14:31 +00:00
Mike Hommey 4b461e269a Bug 1543009 - Move Windows DHCP client xpcom component to static registration. r=kmag
Differential Revision: https://phabricator.services.mozilla.com/D26892
2019-04-11 16:23:52 +09:00
Mike Hommey 1b87806fdc Bug 1541792 - Replace linker magic with manual component registration. r=froydnj
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.

Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.

Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.

Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.

Differential Revision: https://phabricator.services.mozilla.com/D26076
2019-04-05 02:30:56 +00:00
Sylvestre Ledru e5a134f73a Bug 1511181 - Reformat everything to the Google coding style r=ehsan a=clang-format
# ignore-this-changeset
2018-11-30 11:46:48 +01:00
Ehsan Akhgari b614d2046a Bug 1508472 - Part 5: Fifth batch of comment fix-ups in preparation for the tree reformat r=sylvestre
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.

Differential Revision: https://phabricator.services.mozilla.com/D13371
2018-11-29 10:30:46 +00:00
Polly Shaw 723759fe28 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
2018-06-07 23:07:28 +01:00
Andreea Pavel 842a6663b7 Backed out changeset a7a1006e2f52 (bug 356831) for braking marionette on win asan on a CLOSED TREE 2018-07-10 18:42:01 +03:00
Polly Shaw 9818e26aae 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
2018-06-07 23:07:28 +01:00
Valentin Gosu 4bb729eb0b Bug 1456863 - Backed out bug 356831 (changeset 204bb43af943) for leaks r=me 2018-04-30 15:34:39 +02:00
Polly Shaw 12d4f954e2 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
2018-04-22 18:13:11 +01:00
Margareta Eliza Balazs 1c02375b6e Backed out changeset 2a760b1c0759 (bug 356831) for adding files without having a bugzilla product and component 2018-04-24 19:33:00 +03:00
Polly Shaw a516009546 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
2018-04-22 18:13:11 +01:00