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