Removes references to now unused pref that was added in bug 868441 and removed in bugs 913807 and 1054572. It also removes some leftovers from http channel which have not been removed in those 2 bugs.
There's one redudant NS_ShouldCheckAppCache(nsIURI*, bool) is not used
anymore. Also we remove the extra usePrivateBrowsing argument, since we
can get this information from nsIPrincipal.
The blocking transactions should be dispatched before other transactions. So, this patch aims to put those transactions in front of the pending queue.
Moreover, also give the rest available connections to background tab when processing pendingQ for all entries.
Currently nsBufferedInputStream is able to Fill() data only from sync
inputStream. When a page uses XHR to upload something, it creates a
nsBufferedInputStream around the source inputStream. This stream can be a
IPCBlobInputStream, and in that case, the reading is only supported using
nsIAsyncInputStream interface. nsBufferedInputStream must support it.
// When non empty all non-localhost DNS queries (including IP addresses)
// resolve to this value. The value can be a name or an IP address.
// domains mapped to localhost with localDomains stay localhost.
pref("network.dns.forceResolve", "");
Testing is the primary use case here - replay captive data on a 'fake
server' by directing all traffic to it at the DNS level. Chrome has
something similar.
MozReview-Commit-ID: 7AOgQZpZKec
--HG--
extra : rebase_source : ad2648a701fffecaae47cbfae17e7aa6badd50ee
Some protocol handlers don't handle speculative connections too well
(they crash). So, we limit to the most useful protocols. This patch
brought to you by
https://bugzilla.mozilla.org/show_bug.cgi?id=1348278#c21
MozReview-Commit-ID: 8dWGdVtalIS
--HG--
extra : rebase_source : 9ba674282e40d8313fdb8fbd2f1b9ae7567d299d
mRacingNetAndCache used to be set in TriggerNetwork, when the network was triggered before the cache callbacks had been called, but this could also happen when we bypassed the cache.
MozReview-Commit-ID: 4CklwPVRGar
--HG--
extra : rebase_source : 47a604e25ce879b929dbb2eba7bca36e371845ae
This change makes the code a little cleaner and reduces the number of
places we call PR_GetCurrentThread, which is important for Quantum DOM
scheduling work.
The conversion was largely automatic, via:
find netwerk/ -name \*.cpp | \
xargs sed -i -e 's/MOZ_ASSERT(PR_GetCurrentThread() == gSocketThread[^;]*/MOZ_ASSERT(OnSocketThread(), "not on socket thread")/'
and related invocations, with a few manual tweaks at the end.
Change mozilla::Smprintf and friends to return a UniquePtr, rather than
relying on manual memory management. (Though after this patch there are
still a handful of spots needing SmprintfFree.)
MozReview-Commit-ID: COa4nzIX5qa
--HG--
extra : rebase_source : ab4a11b4d2e758099bd0794d5c25d799a7e42680
nsInputStreamPump should use the stream as nsIAsyncInputStream if available.
In order to do so, we need to wrap a BufferedStream around it.
MediaResource cannot use a simple sync nsIInputStream when BlobURL are involved
in the content process.
Serializing and sending IPC messages takes a lot of time, and it gets in the way of image loading. Making this functionality async gets out of the way of image loading (among other things).
The test has been changed to pump the main thread after calling predictor.learn so the multiprocess version can actually run to completion. This isn't strictly necessary in the single process version, but it makes the code changes (which are already pretty invasive) simpler.
MozReview-Commit-ID: 7jvhomlygbf
--HG--
extra : rebase_source : a779a498f83a2b02d2d634eff63d15f483793046
the protocol proxy service asserts that is in a clean state at dtor -
normally this happens through observe("xpcom-shutdown") but its
actually possible of other events in the xpcom run queue to
'unitialize' things before the dtor.. add a state in which fail codes
are returned instead.
MozReview-Commit-ID: XaNQEZUsRP
--HG--
extra : rebase_source : 054b01269d36dd8e8e24056f389c94a0d9183436
nsInputStreamPump should use the stream as nsIAsyncInputStream if available.
In order to do so, we need to wrap a BufferedStream around it.
MediaResource cannot use a simple sync nsIInputStream when BlobURL are involved
in the content process.
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements.
netwerk/protocol/http/Http2Stream.cpp:436:59 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: AsmNPTjKlYB
--HG--
extra : rebase_source : f25e62c3ac95b2b2cc412f82a8282591371f4925
extra : source : 9a1518b310c517ea81e78421c1479cfa14c8b17a
StringBundle caches bundles, so when language chain changes we should
flush the cache to enable new strings to be loaded.
This also affects localized prefs like intl.accept_languages.
Then in HttpHandler we have to mark the value as dirty so that next
time it's called it actually recalculates using flushed string bundle
with the new locale.
MozReview-Commit-ID: DKWEDUli4yH
--HG--
extra : rebase_source : 75ecc4204deca066d7492d1494492a91685f36be
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
This implements a plaintext reading of RFC 6797, which says to only consider the
first, however it slightly conflicts with RFC 7230, which says that sending
multiple headers which can't be merged is illegal (except for a specific
whitelist which HSTS isn't in). Chrome also implements HSTS using RFC 6797's
description of the parsing algorithm.
r=mcmanus,keeler
MozReview-Commit-ID: E06uIk2IcEK
--HG--
extra : rebase_source : 4a67f067d2953d4b30c1019a61bbfc7073e55b3d
NS_SetCurrentThreadName() is added as an alternative to PR_SetCurrentThreadName()
inside libxul. The thread names are collected in the form of crash annotation to
be processed on socorro.
MozReview-Commit-ID: 4RpAWzTuvPs
In the past we used a fixed value for the firstPartyDomain of
NullPrincipal, now we derive it from the path of NullPrincipal, so it
will be unique everytime we create it.
This helper class allows us to create simple channels that open an underlying
input stream when the channel is first opened, using a closure function,
without having to expose the nsBaseChannel class to non-necko code.
MozReview-Commit-ID: 6jiImdMXUp0
--HG--
extra : rebase_source : b8d30a28593940c41109b1352eb0c549213c5f89
Several of our simple channel implementations work naturally with direct
nsIStreamListener output. Currently, these implementations need to create a
pipe, pump data in to that pipe, and then allow nsBaseChannel to pump data out
of the other side of that pipe, into its own stream listener.
This change allows them to output data directly to nsBaseChannel's stream
listener, which removes unnecessary complexity and overhead.
MozReview-Commit-ID: JCGKTt6Kn9x
--HG--
extra : rebase_source : 200dd2641bfa703f658c2c5171a68df3a035be0a
They have generic names, and are potentially conflicting with
in-tree headers with the same name (which is true for at least port.h).
There aren't enough users of brotli to want to avoid LOCAL_INCLUDES
in the directories that use it.
--HG--
extra : rebase_source : 82531ac5961ad80e1b3d0c1484a2f146be194411
If the call to NewChannel2 returns NS_ERROR_NOT_IMPLEMENTED or NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED that means the implementation is actually missing, so it is OK to fall back to NewChannel.
If it fails with any other error code, we just return it.
MozReview-Commit-ID: JmgEmPqu6zJ
--HG--
rename : netwerk/test/unit/test_bug894586.js => netwerk/test/unit/test_1351443-missing-NewChannel2.js
extra : rebase_source : 5d41df330a15ad7b679d9bed52e6fbf90bdc4ed8
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : 071a9cb1769f013717357458df24e2fd9570ccf4
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : fe3c9480cee468aa2a24fd34e569b58e4f2c9c9a
To make sure the last (unknown) entry is always -1.
Also, nsDirIndexParser::ParseFormat() must return OK even when bailing
out early to not cause subsequent problems.
--HG--
extra : rebase_source : fea969159e73ff2f438dd42559e87ad8eb183acf
Since we cannot call .First() on it and since it clearly contains
nothing to show anyway!
--HG--
extra : source : ecd714c21c5bd643875d85101dccaaeff18bd350
extra : amend_source : 22307168ed9289c36dade3f33a7c3ded93b5612c
This updates the unifed sources for a few netwerk build files. In some cases
files were excluded because we thought they used plarena.h, but that turned
to be false.
A few files needed to be updated to add missing imports/exports due to shifting
of compilation units.
MozReview-Commit-ID: 4mh8VApFoe1
This updates the unifed sources for a few netwerk build files. In some cases
files were excluded because we thought they used plarena.h, but that turned
to be false.
A few files needed to be updated to add missing imports/exports due to shifting
of compilation units.
MozReview-Commit-ID: 4mh8VApFoe1