TestNetworkLinkIdHashingWindows has two issues that, frighteningly, cancelled each other out under most conditions.
First is that the `sscanf` format string uses curly braces when the test data does not have braces.
Second is that the order of `nwGUIDS` does not match the sorting behavior of `nsNotifyAddrListener::HashSortedNetworkIds`.
What ended up happening was that the sscanf failed, and left the entire GUID uninitialized. Then we used that uninitialized data over and over in `nwGUIDS` so the order didn't matter. However, under AddressSanitizer, the failure became evident, because (I think, haven't verified) that ASan's instrumentation messes with the contents of the stack between the four GUID parses, so we no longer use the same uninitialized data four times. And for bonus fun, this wasn't noticed in CI because we don't (yet) run ASan on GTests for Windows.
Debugging this was... quite an adventure.
Differential Revision: https://phabricator.services.mozilla.com/D63532
--HG--
extra : moz-landing-system : lando
When it's first starting up, when mConfirmationState != CONFIRM_OK
the TRR service is not ready to use.
For TRR_FIRST requests we need to fallback to DNS while the service starts up.
Differential Revision: https://phabricator.services.mozilla.com/D61218
--HG--
extra : moz-landing-system : lando
When it's first starting up, when mConfirmationState != CONFIRM_OK
the TRR service is not ready to use.
For TRR_FIRST requests we need to fallback to DNS while the service starts up.
Differential Revision: https://phabricator.services.mozilla.com/D61218
--HG--
extra : moz-landing-system : lando
When it's first starting up, when mConfirmationState != CONFIRM_OK
the TRR service is not ready to use.
For TRR_FIRST requests we need to fallback to DNS while the service starts up.
Differential Revision: https://phabricator.services.mozilla.com/D61218
--HG--
extra : moz-landing-system : lando
This change is backwards incompatible with the older cookies.sqlite
files, which means files saved from newer versions of Firefox will
no longer be possible to open in older versions of Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D60464
--HG--
rename : netwerk/test/unit/test_schema_3_migration.js => netwerk/test/unit/test_schema_10_migration.js
extra : moz-landing-system : lando
This change is backwards incompatible with the older cookies.sqlite
files, which means files saved from newer versions of Firefox will
no longer be possible to open in older versions of Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D60464
--HG--
rename : netwerk/test/unit/test_schema_3_migration.js => netwerk/test/unit/test_schema_10_migration.js
extra : moz-landing-system : lando
Fetch, configure, and run node for Android on the test host, just like Linux tests do.
Make the node/HTTP/2 environment variables available to the tests on the device, and
use adb port forwarding to connect sockets. Finally, enable tests skipped for node.
Differential Revision: https://phabricator.services.mozilla.com/D60204
--HG--
extra : moz-landing-system : lando
Fetch, configure, and run node for Android on the test host, just like Linux tests do.
Make the node/HTTP/2 environment variables available to the tests on the device, and
use adb port forwarding to connect sockets. Finally, enable tests skipped for node.
Differential Revision: https://phabricator.services.mozilla.com/D60204
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
The forced garbage collection has been added a decade ago for a test that
exhibited a memory increase over time in Firefox. Now that the test is no
longer present in the tree, and the garbage collector got a lot of improvements
over the last years, there is no compelling reason to keep the call to
"forceGC()" in the closing handler of httpd.js.
Differential Revision: https://phabricator.services.mozilla.com/D58550
--HG--
extra : moz-landing-system : lando
On windows 10-64 asan, we get a failure on the network io test that
checks the sqlite DB is touched. According to the logs, this failure
happens because when the test occurs the write happens in the wal
file. Adapted the test to also check for that location.
Differential Revision: https://phabricator.services.mozilla.com/D58908
--HG--
extra : moz-landing-system : lando
This is something less hacky to the best of my knowledge. Both passing preferable proxy table and letting system setting handle `ws`/`wss` touch the code of all platforms, which is more fragile.
Differential Revision: https://phabricator.services.mozilla.com/D57176
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This patch adds DefaultURI which wraps MozURL which in turn forwards calls
to rust-url.
For the moment the added network.url.useDefaultURI is set to false by default.
The plan is to make this the default implementation for unknown URI types.
Differential Revision: https://phabricator.services.mozilla.com/D54748
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
It should be illegal to add paths that cannot be handled/accessed
or later referenced. Without a path, it is for example later
impossible to delete the handler.
To address this we return an NS_ERROR_INVALID_ARG when
nsIHttpServer.registerPathHandler is called with an empty string.
Differential Revision: https://phabricator.services.mozilla.com/D55160
--HG--
extra : moz-landing-system : lando
- Adds the `network.trr.enable_when_vpn_detected` defaulting to false. This means detecting a PPP adapter will make IsExcludedFromTRR always return true - it does not affect the `network.trr.mode` pref.
- Adds a test that when nsINetworkLinkService.vpnDetected is true we skip all TRR requests
- Makes it so we update the excludedDomains list and VPN detected status for TRR on any network:link-status-changed observer notification that is received.
Differential Revision: https://phabricator.services.mozilla.com/D53356
--HG--
extra : moz-landing-system : lando
This patch fixes two issues where we may mistakenly load a TRR record even though the host is part of the excluded-domains list:
1. If a.com is part of the excluded domains, but b.com is not, then when we first resolve b.com using TRR, the server may also push the record for a.com; Previously we didn't check if the pushed record is also excluded, which could lead us to load it from the TRR cache.
2. If b.com is resolved using TRR, but later b.com is added to the excluded-domains list, we may mistakenly load b.com from the TRR cache, even though we should use platform DNS for it.
Differential Revision: https://phabricator.services.mozilla.com/D53354
--HG--
extra : moz-landing-system : lando
- Adds the `network.trr.enable_when_vpn_detected` defaulting to false. This means detecting a PPP adapter will make IsExcludedFromTRR always return true - it does not affect the `network.trr.mode` pref.
- Adds a test that when nsINetworkLinkService.vpnDetected is true we skip all TRR requests
- Makes it so we update the excludedDomains list and VPN detected status for TRR on any network:link-status-changed observer notification that is received.
Differential Revision: https://phabricator.services.mozilla.com/D53356
--HG--
extra : moz-landing-system : lando
The signatureInfo that has been used in ExternalHelperAppService and
ReputationService has been stored Array of nsIX509CertList, which
isn't necessary because only the raw bytes of the certs are required.
This patch intends to remove the usage of nsIX509CertList and store
the raw bytes directly.
Differential Revision: https://phabricator.services.mozilla.com/D44243
--HG--
extra : moz-landing-system : lando
- changes moz-http2.js so that the pushed entry is created using dnsPacked.encode in order to make the code clearer
- the pushed TRR entry is not push.example.org (instead of push.example.com) so the pushed entry is not same origin with the DoH endpoint.
- makes sure that when checking DnsSuffixInMode(3) we have the bootstrap address set
Differential Revision: https://phabricator.services.mozilla.com/D52912
--HG--
extra : moz-landing-system : lando
When using add_task to schedule the tests, testEsniPushPart2 would always fail.
That's because Bug 1587875 now clears the DNS cache when the network.trr.uri
pref is changed. This is likely intermittent because of task scheduling.
This patch modernizes the test to use add_task and promises, and sets the
network.trr.clear-cache-on-pref-change;true pref so the test performs its
checks properly.
Differential Revision: https://phabricator.services.mozilla.com/D52825
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
Using a data URL makes the request not use the proxy and so it will not mess up the session count
Differential Revision: https://phabricator.services.mozilla.com/D51843
--HG--
extra : moz-landing-system : lando
* Adds a new moz-http2-child.js file which gets spawned into a new process. When calling NodeServer.execute, the code gets passed to the existing moz-http2.js process which then sends it to be evaluated in the child process. Any crash in the child should not be able to kill the main node process.
* Moves the proxy creation code into test_http2-proxy.js
* Adds the new NodeServer.fork() and NodeServer.kill() static methods to spawn a new server
* Makes it easier to isolate a test's behaviour from another's. It also opens the way to moving some of the logic to individual unit tests, like we do for the proxy creation code, rather than keeping it all in moz-http2.js
Differential Revision: https://phabricator.services.mozilla.com/D49961
--HG--
extra : moz-landing-system : lando
* Adds a new moz-http2-child.js file which gets spawned into a new process. When calling NodeServer.execute, the code gets passed to the existing moz-http2.js process which then sends it to be evaluated in the child process. Any crash in the child should not be able to kill the main node process.
* Moves the proxy creation code into test_http2-proxy.js
* Adds the new NodeServer.fork() and NodeServer.kill() static methods to spawn a new server
* Makes it easier to isolate a test's behaviour from another's. It also opens the way to moving some of the logic to individual unit tests, like we do for the proxy creation code, rather than keeping it all in moz-http2.js
Differential Revision: https://phabricator.services.mozilla.com/D49961
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
This is where it should have been in the first place. Those attributes belong there.
Differential Revision: https://phabricator.services.mozilla.com/D49577
--HG--
extra : moz-landing-system : lando
This test was originally written to test HTTPResponseProcessSelection before it
was hooked up into the process switch machinery. It hooks into some parts of the
process switch process which should probably be removed in the future (such as
overriding the child listener component registration), and is broken under
fission anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47313
--HG--
extra : moz-landing-system : lando
This test was originally written to test HTTPResponseProcessSelection before it
was hooked up into the process switch machinery. It hooks into some parts of the
process switch process which should probably be removed in the future (such as
overriding the child listener component registration), and is broken under
fission anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47313
--HG--
extra : moz-landing-system : lando
This test was originally written to test HTTPResponseProcessSelection before it
was hooked up into the process switch machinery. It hooks into some parts of the
process switch process which should probably be removed in the future (such as
overriding the child listener component registration), and is broken under
fission anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47313
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
Differential Revision: https://phabricator.services.mozilla.com/D46642
--HG--
extra : moz-landing-system : lando
Will allow for SessionStore.jsm process switching to be used by other objects than nsHttpChannel.
Differential Revision: https://phabricator.services.mozilla.com/D46015
--HG--
extra : moz-landing-system : lando
Will allow for SessionStore.jsm process switching to be used by other objects than nsHttpChannel.
Differential Revision: https://phabricator.services.mozilla.com/D46015
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
DocumentChannel acts as a replacement for HttpChannel where redirects are now entirely handled in the DocumentChannelParent. The ContentChild will receive the final nsIChannel once all redirects have been handled.
Differential Revision: https://phabricator.services.mozilla.com/D37490
Currently, TabGroups know to break their reference cycles only when the last
window leaves them. For TabGroups which have never had a window join (which
happens under Fission), this means they also never see a window leave, and
therefore never break their reference cycles, and leak.
This patch adds a check to break reference cycles if no windows have joined by
the time a BrowserChild they belong to is destroyed.
MANUAL PUSH: Lando fails to rebase.
Differential Revision: https://phabricator.services.mozilla.com/D40669
--HG--
extra : source : 03acb28ab60fb77fa06064385a62cc46cf4ad1bd
extra : amend_source : 0a71625d99951bebe45ee6f62570de491a714e97
Fix for the Bug 1536744 removed abiliti for nsIProtocolHandler to parse URLs of the
custom protocols & broke libdweb. In order to fix followup change for Bug 1559356 introduced a
whitelist for dweb: and dat: protocols to parse those as nsIStandardURLs. This change extends
whitelist with ipfs: ipns: ssb: schemes and ext+ prefix scheme.
This would allow Bug 1271553 to progress until better more general solution can be implemnted.
Differential Revision: https://phabricator.services.mozilla.com/D39463
--HG--
extra : moz-landing-system : lando
Fix for the Bug 1536744 removed abiliti for nsIProtocolHandler to parse URLs of the
custom protocols & broke libdweb. In order to fix followup change for Bug 1559356 introduced a
whitelist for dweb: and dat: protocols to parse those as nsIStandardURLs. This change extends
whitelist with ipfs: ipns: ssb: schemes and ext+ prefix scheme.
This would allow Bug 1271553 to progress until better more general solution can be implemnted.
Differential Revision: https://phabricator.services.mozilla.com/D39463
--HG--
extra : moz-landing-system : lando
Sometimes we don't have origin like OCSP requests, or a fetch issues from web extension.
We should not send `Origin:`
Spec doesn't specify how to treat other protocol like moz-extension.
IMO we should also prevent sending `Origin:` to keep web-compat.
Differential Revision: https://phabricator.services.mozilla.com/D39595
--HG--
extra : moz-landing-system : lando
Does it matter how nsIMIMEService is obtained? I wouldn't think so, tests continue
to pass with this change, and this will allow me to move ahead with running
xpcshell against geckoview.
Differential Revision: https://phabricator.services.mozilla.com/D39512
--HG--
extra : moz-landing-system : lando
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
Valentin Gosu
Arthur Iakab
Andrea Marchesini
Noemi Erli
Andreea Pavel
David Major
Neil Deakin
Masatoshi Kimura
Christian Holler
Honza Bambas
Dragana Damjanovic
Razvan Maries
Kershaw Chang
Ehsan Akhgari
Bogdan Tara
Coroiu Cristina
Geoff Brown
Narcis Beleuzu
Ting-Yu Lin
Dorel Luca
Matt Woodrow
Magnus Melin
Sylvestre Ledru
Henrik Skupin
Tarek Ziadé
Junior Hsu
Kris Maglione
Geoff Lankow
shindli
Daniel Varga
Gabriele Svelto
Ciure Andrei
Andreas Tolfsen
Sebastian Streich
Andrew McCreight
Cosmin Sabou
Sean Feng
Moritz Birghan
Mihai Alexandru Michis
Oana Pop Rus
Jean-Yves Avenard
Nika Layzell
Ben Campbell
Csoregi Natalia
Brindusan Cristian
Jonathan Kingston
Paul Zuehlcke
Henri Sivonen
Jeremy Lempereur
Gurzau Raul
Paul Bone
Thomas Nguyen
Liang-Heng Chen
Abdoulaye O. Ly
Jon Coppeard
Jared Wein
Irakli Gozalishvili
Boris Zbarsky
Joel Maher
Victor Porof
Nicholas Hurley
avneeshsinghal
Emilio Cobos Álvarez
Edwin Gao
Gijs Kruitbosch
Ryan Hunt