In order to optionally report the full hash back to Google, we need to keep it
around in the callback. While a prefix is not the same as a full hash (multiple
full hashes can map to the same prefix), in this case, the callback will only be
called when the full hash matches.
MozReview-Commit-ID: F4WSLZpYrXB
--HG--
extra : rebase_source : da3b16b00729d0aa6ff1765a135b751fcf44c012
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
This flags is added in the http channel interface by which developers can control the TLS
connections from JavaScript code (e.g. Add-ons). Basically, all the changes accounted for
plumbing this TLS flags from JavaScript level to C++ code responsible for calling NSS
module. We also added a unit test to make sure that separate connections are created if we
use different tlsFlags. Basically we used a concrete set of flag values that covers the
edge cases and check the hashkey generated in the connection info.
--HG--
rename : netwerk/test/unit/test_separate_connections.js => netwerk/test/unit/test_tls_flags_separate_connections.js
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
nsIURI.originCharset had two use cases:
1) Dealing with the spec-incompliant feature of escapes in the hash
(reference) part of the URL.
2) For UI display of non-UTF-8 URLs.
For hash part handling, we use the document charset instead. For pretty
display of query strings on legacy-encoded pages, we no longer care to them
(see bug 817374 comment 18).
Also, the URL Standard has no concept of "origin charset". This patch
removes nsIURI.originCharset for reducing complexity and spec compliance.
MozReview-Commit-ID: 3tHd0VCWSqF
--HG--
extra : rebase_source : b2caa01f75e5dd26078a7679fd7caa319a65af14
During abnormal shutdown, HttpChannelChild might be released on STS thread. However, not all stream listener
that attached to the HTTP channel is thread-safe to be released on non-main thread. By following
HttpBaseChannel::ReleaseListener, we should ensure mListener/mListenerContext/mCompressListener is released on
main thread for both normal channel close and abnormal shutdown scenario.
MozReview-Commit-ID: Gqbk7dUOIcI
--HG--
extra : rebase_source : 1ce6eb1333b05c375469c2fef6284c11fda24f3e
Implements PerformanceTiming, nsITimedChannel, and devtools 'tls setup'
Also captures telemetry on this as we do for all other attributes of timedChannel
Also propogates some null transaction timings onto first real
transaction of a connection
MozReview-Commit-ID: 47TQJYVHnKC
--HG--
extra : rebase_source : a7723962986de0c2ab00d479a22c3f5fd185c8b2
Since the uri classifier needs topWindowURI to decide whether or not to enable channel annotation, we have to allow to change this attribute in js for passing the test.
--HG--
extra : rebase_source : c5effa05fecef0d32600e4c9c926dbfa77c2ca6f
The channel objects cannot be handed off to other threads before the creation
process has been finished, so there is no point in trying to hold these locks
while the initialization code is running. These lockings have shown up in
profiles as being expensive.
