When a test crashes, the harness skips all of the remaining tests in the
directory. That means that with crashes skipped, we now try to run a whole lot
more tests than we did before, and a lot of them fail under Fission.
This patch adds annotations to the new failures that show up after part 1.
Differential Revision: https://phabricator.services.mozilla.com/D38726
--HG--
extra : rebase_source : 292157039c88fc615f5de41679e96e72766ac4db
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
Since JSWindowActors don't have direct access to synchronous messaging,
ChromeScript callers are going to need to migrate to asynchronous messaging
and queries instead.
Since there's no comparable API to sendQuery for frame message managers, this
patch adds a stub that uses synchronous messaging, but makes the API appear
asynchronous, and migrates callers to use it instead of direct synchronous
messaging. This will be replaced with a true synchronous API in the actor
migration.
Fortunately, most of the time, this actually leads to simpler code. The
`sendQuery` API doesn't have the odd return value semantics of
`sendSyncMessage`, and can usually just be used as a drop-in replacement. Many
of the `sendSyncMessage` callers don't actually use the result, and can just
be changed to `sendAsyncMessage`. And many of the existing async messaging
users can be changed to just use `sendQuery` rather than sending messages and
adding response listeners.
However, the APZ code is an exception. It relies on intricate properties of
the event loop, and doesn't have an easy way to slot in promise handlers, so I
migrated it to using sync messaging via process message managers instead.
Differential Revision: https://phabricator.services.mozilla.com/D35055
--HG--
extra : rebase_source : d5707e87f293a831a5cf2e0b0a7e977090267f78
extra : source : 75ebd6fce136ab3bd0e591c2b8b2d06d3b5bf923
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
We want dweb URLs to continue working as before bug 1536744 landed.
So we make sure to instantiate it as an nsStandardURL.
This is not a good long-term solution, as we don't want to hardcode
all the various schemes that we want to behave properly.
The fix would be to add a new spec-compliant nsIURI implementation,
based on RustURL and use it for all unknown schemes.
See bug 1561860 for a more complete solution.
Differential Revision: https://phabricator.services.mozilla.com/D36168
--HG--
extra : moz-landing-system : lando
Previously we would throw in nsFtpProtocolHandler::NewURI. Since that doesn't exist anymore, and creating FTP URLs always works, we need to make sure creating the FTP channel doesn't work anymore.
Differential Revision: https://phabricator.services.mozilla.com/D35642
--HG--
extra : moz-landing-system : lando
This patch adds:
* tests that we restart the TRR connection if it gets abnormally shut down
* a way to terminate the TRR connection when attempting to resolve closeme.com
* makes sure that resolving excluded domains with the DISABLE_TRR flag does
not fail. Before this we would return an error code without checking the
excluded domains first.
Differential Revision: https://phabricator.services.mozilla.com/D35076
--HG--
extra : moz-landing-system : lando
Origin: honors ReferrerPolicy: so we should honor defaultPolicy set by user
Differential Revision: https://phabricator.services.mozilla.com/D34979
--HG--
extra : moz-landing-system : lando
Changes:
- move xpcshell from macosx1010 to macosx1014
- updated regex for macosx1014 xpcshell to run on 2 chunks for all variants (for now)
Differential Revision: https://phabricator.services.mozilla.com/D34561
--HG--
extra : moz-landing-system : lando
The problem with CaptiveDetect was that it uses an XMLHttpRequest, and
apparently xhr.status is 0 for failed requests, which here includes cert
errors, redirect loops, etc.
Getting the XHR to not follow redirects was tricky, so a hacky fix was to
set nsIHttpChannel.redirectionLimit = 0;
For any redirect the XHR would now fail with NS_ERROR_REDIRECT_LOOP, which
we need to handle separately.
I also included tests for:
* redirect to https with invalid cert
* redirect to same URL causing redirect loop
* redirect to different URL with different content
* redirect to different URL with canonical content
All of these cases should be detected as locked captive portals.
Differential Revision: https://phabricator.services.mozilla.com/D33706
--HG--
extra : moz-landing-system : lando
Normally, this method will return the entire in string if it has a scheme.
However, mParser->ParseURL may fail, leading to the scheme to be cleared,
and the result will be the same HTTP URL with the input appended to the
path. This triggers the assertion in NS_NewURI that the scheme should not
change.
As a fix, we bail out of nsStandardURL::Resolve() if the parsed scheme of
the input is different than the base URIs current scheme. This condition
is necessary, because we still need to support a deprecated form of relative
URLs like http:file or http:/path/file
Differential Revision: https://phabricator.services.mozilla.com/D33003
--HG--
extra : moz-landing-system : lando
This test uses prefs added in Bug 1518730, but the pref is ignored when it
doesn't exist, so the test is still valid.
Depends on D33471
Differential Revision: https://phabricator.services.mozilla.com/D33473
--HG--
extra : moz-landing-system : lando
Normally, this method will return the entire in string if it has a scheme.
However, mParser->ParseURL may fail, leading to the scheme to be cleared,
and the result will be the same HTTP URL with the input appended to the
path. This triggers the assertion in NS_NewURI that the scheme should not
change.
As a fix, we bail out of nsStandardURL::Resolve() if the parsed scheme of
the input is different than the base URIs current scheme. This condition
is necessary, because we still need to support a deprecated form of relative
URLs like http:file or http:/path/file
Differential Revision: https://phabricator.services.mozilla.com/D33003
--HG--
extra : moz-landing-system : lando
The only protocol that can't be created off the main thread at the moment is
moz-extension, and that can be handled at a later time.
Differential Revision: https://phabricator.services.mozilla.com/D30713
--HG--
extra : moz-landing-system : lando
According to the spec, we should ignore the response body for the HEAD and CONNECT requests.
Differential Revision: https://phabricator.services.mozilla.com/D28678
--HG--
extra : moz-landing-system : lando
This code currently works for remote subframes assuming that nsIRemoteTab is implemented
by BrowserParent, but will break when nsIRemoteTab is only for a top-level BrowserParent.
What this code really wants is a content process ID to retarget the channel to. This
commit switches the interfaces to pass this around instead of nsIRemoteTab.
Differential Revision: https://phabricator.services.mozilla.com/D31435
--HG--
extra : source : 757b4f595cc4b18ae35483d23edff4896d15d4b1
This code currently works for remote subframes assuming that nsIRemoteTab is implemented
by BrowserParent, but will break when nsIRemoteTab is only for a top-level BrowserParent.
What this code really wants is a content process ID to retarget the channel to. This
commit switches the interfaces to pass this around instead of nsIRemoteTab.
Differential Revision: https://phabricator.services.mozilla.com/D31435
--HG--
extra : rebase_source : be3303c2d38d704a6a1817fa45fd76700fae6287
extra : histedit_source : c7bf1e496f4328acc9ee70fcccdff98ea2cce5df
At the end of each test, file_chromecommon.js deletes all the cookies, but it
doesn't invalidate the network cache. Some of the files are shared between
tests. When they are loaded from the cache, we don't set the cookies and,
because of this, the tests were reporting a wrong cookie number.
Differential Revision: https://phabricator.services.mozilla.com/D31596
--HG--
extra : moz-landing-system : lando
Since the SubstitutingProtocolHandler is also extended by nsResProtocolHandler, this change would also apply to resource:// URLs.
Differential Revision: https://phabricator.services.mozilla.com/D30344
--HG--
extra : moz-landing-system : lando
This patch fixes some build issues on Android and also enables some gtests.
Differential Revision: https://phabricator.services.mozilla.com/D30386
--HG--
extra : moz-landing-system : lando
With changes from bug 1548555, one of the gtests previously disabled on Android
can be re-enabled, but most of the tests in netwerk/test/gtest are still problematic
(some won't build for me).
Differential Revision: https://phabricator.services.mozilla.com/D30081
--HG--
extra : moz-landing-system : lando
These tests need to be disabled to get a green run on the Android x86_64
test platform. The failures in toolkit/components/extensions are
concerning and definitely require follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29843
--HG--
extra : moz-landing-system : lando
Changes:
- most tests are skipped using `moz.build` configuration file.
- `MultiWriterQueue` had to be skipped with `define` clauses in the test file due to build bustages when its `moz.build` file was used.
Differential Revision: https://phabricator.services.mozilla.com/D27944
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
The module is manually registered through the component manager in
the gtest setup anyways.
Differential Revision: https://phabricator.services.mozilla.com/D26063
--HG--
extra : moz-landing-system : lando
Normally you wouldn't want localhost or *.local domain to be resolved by a
remote resolver.
This patch makes sure that even if we are in TRR-only mode, we still
successfully resolve the domains specified by network.trr.excluded-domains
using native DNS.
Also fixes bug in TRRService::ReadPrefs where we didn't clear mExcludedDomains
before reading the pref.
Differential Revision: https://phabricator.services.mozilla.com/D24380
--HG--
extra : moz-landing-system : lando
It is likely that the test is flaky because we resolve the same host with a different TRR endpoint and sometimes we use a cached record.
We should clear the DNS cache before each test to ensure that we're actually checking the right thing.
Differential Revision: https://phabricator.services.mozilla.com/D24355
--HG--
extra : moz-landing-system : lando
Some testcases are chrome scope testcase hence the resources it loads are triggered by
"system principal". This will exempt the resource from classification.
So in this patch, we used a new window to for the tracker test frame.
The window creation code is referenced from test_privatebrowsing_trackingprotection.html.
Differential Revision: https://phabricator.services.mozilla.com/D22114
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
Some testcases are chrome scope testcase hence the resources it loads are triggered by
"system principal". This will exempt the resource from classification.
So in this patch, we used a new window to for the tracker test frame.
The window creation code is referenced from test_privatebrowsing_trackingprotection.html.
Differential Revision: https://phabricator.services.mozilla.com/D22114
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
Disable the following tests, with 1536211 serving as the tracking bug:
- test_header_Server_Timing.js (1530871)
- test_trr.js (1532395)
- test_esni_dns_fetch.js (1530752)
Differential Revision: https://phabricator.services.mozilla.com/D23922
--HG--
extra : moz-landing-system : lando
Due to the p1 patch, the first time we get the result back from NS_ShouldSecureUpgrade is always asynchronously.
This means that the first http request could be completed slower than the http requests opened after the first one. There are some tests affected by this change, since these tests assume that http requests should be completed in the same order as these requests were created.
This patch fixes the tests by introducing a new method in nsIHttpProtocolHandler. This method returns a promise and makes sure the HSTS data is ready to read synchronously when the promise is resolved.
Once the HSTS is ready to read, the order of open/close channels will be the same.
Differential Revision: https://phabricator.services.mozilla.com/D21683
--HG--
extra : moz-landing-system : lando
This patch uses the existing xpcshell test certificate infrastructure
(pycert/pykey) to manage the http2 test certificates (and gets rid of some uses
of nsIBadCertListener2 as a bonus).
Differential Revision: https://phabricator.services.mozilla.com/D21814
--HG--
rename : netwerk/test/unit/CA.cert.der => netwerk/test/unit/http2-ca.pem
rename : testing/xpcshell/moz-http2/http2-key.pem => testing/xpcshell/moz-http2/http2-cert.key
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 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
Andreea Pavel
Abdoulaye O. Ly
Boris Zbarsky
Ciure Andrei
Kris Maglione
Kershaw Chang
Joel Maher
Dorel Luca
Thomas Nguyen
Gurzau Raul
Brindusan Cristian
Jonathan Kingston
Victor Porof
Valentin Gosu
Nicholas Hurley
avneeshsinghal
Junior Hsu
Cosmin Sabou
Emilio Cobos Álvarez
Edwin Gao
Gijs Kruitbosch
Sylvestre Ledru
Andrea Marchesini
shindli
Honza Bambas
Christian Holler
Csoregi Natalia
arthur.iakab
Bogdan Tara
Mihai Alexandru Michis
Daniel Varga
Ryan Hunt
Dragana Damjanovic
Ehsan Akhgari
Geoff Brown
J.C. Jones
Narcis Beleuzu
Razvan Maries
Andrew McCreight
Brian Grinstead
Mike Hommey
Jeremy Lempereur
Ian Moody
Mark Banner
dlee
Jan Varga
Dana Keeler
Michal Novotny
Christoph Kerschbaumer
Nika Layzell
Jorg K
vinoth
Dave Townsend
Margareta Eliza Balazs
Paolo Amadini
Michal Novotny
Jeff Walden
Daniel Stenberg
Jonathan Kew
Sebastian Hengst
Fabian Henneke
Simon Montagu
Tooru Fujisawa
Tarek Ziadé
Paul Vitale