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 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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
called if not explicitly requested by the user prefs
The author did not isolate and fix the cause of the assertion failure,
but put in further diagnostics.The author did not isolate and fix the cause of the assertion failure,
but put in further diagnostics.
* an additional assertion was put in on the main thread (which if
triggered would reveal the stack trace)
* in one place where a previously a failure to read the network.proxy.type pref
was ignored, execution of WPAD is now halted with a warning.
Besides these improved diagnostics, in nsPACMan::LoadPACFromURI where an
asynchronous call was made to nsPACMan::StartLoading *before* the preconditions
for this call are set up was changed to be the other way around. The author
suspects that the previous code may have led to race conditions when
LoadPACFromURI was not called from the main thread, although it is not obvious
that this would have caused such a crash.
Differential Revision: https://phabricator.services.mozilla.com/D5388
--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 delays the creation of the PAC thread until we need to dispatch a
runnable to it.
--HG--
extra : rebase_source : dc4bffc041e237dddac7ae36a3a3b2f9c5de3421
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
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
--HG--
extra : rebase_source : cf29f76826cc7728fd36505c8271bf50001c644c
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
--HG--
extra : rebase_source : df2b80fcc03948e54f222e11060e1783f3b95421
Log failures or just ignore them, no control flow change.
MozReview-Commit-ID: D748DEjl3Fv
--HG--
extra : rebase_source : cec54fe99637a2292e9d4ddc6f4131f083da509a
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
This change renames nsILoadContext::GetIsInBrowserElement to
GetIsInIsolatedMozBrowserElement. Other methods that pass these values around
also have name changes.
Tokens such as "isInBrowserElement" have previously been serialized into cache
keys, used as DB column names, stored in app registries, etc. No changes are
made to any serialization formats. Only runtime method and variable names are
updated.
No behavior changes are made in this patch, so some renamed methods may have
nonsensical implementations. These are corrected in subsequent patches
focused on behavior.
MozReview-Commit-ID: CUttXANQjSv