netwerk/protocol/gio/nsGIOProtocolHandler.cpp:89:10: warning: 'return' will never be executed [-Wunreachable-code-return]
This `return NS_ERROR_FAILURE` statement at the end of this function is unreachable because all of the preceding switch statement's cases return.
MozReview-Commit-ID: 3qDu2IqTPrW
--HG--
extra : rebase_source : bcd8a07eee82b60fc071787ccb7df7d9f45d0679
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 patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
CompareCacheHashEntry::mCrit[] is the only case where the nsXPIDLString-ness
was important. The patch adds an explicit SetIsVoid() call to that class's
constructor and changes some null checks to IsVoid() checks.
--HG--
extra : rebase_source : e68befcde4dd098bac2a550bc666eaf3bf1298d7
The spec is already escaped in SetSpec,SetQuery,SetRef - so there is no need to escape it again in the getter.
MozReview-Commit-ID: C0279q5nLXl
--HG--
extra : rebase_source : 726bda4f13bdab7c3e22eed29f6a8cd9bccb024f
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 allows sending and receiving arbitrarily (we limit to 1 GiB atm) sized
messages while not relying on the deprecated PPID fragmentation/reassembly
mode. The code already supports the ndata extension but it's not activated,
yet. Without the SCTP ndata extension, a large data channel message will
monopolise the SCTP association. While this is a problem, it is a temporary
solution until the extension is being activated. Keep in mind that every
application that uses data channels currently does fragmentation/reassembly on
application-level and it's unlikely that this will change until the popular
implementations (libwebrtc) implement EOR as well. Moreover, until the WebRTC
API specifies an API that hands over partial messages, doing application-level
fragmentation/reassembly is still useful for very large messages (sadly).
We fall back to PPID-based fragmentation/reassembly mode IFF a=max-message-size
is not set in the SDP and the negotiated amount of SCTP inbound streams is
exactly 256. Other implementations should avoid using this combination (to be
precise, other implementations should send a=max-message-size).
It also changes behaviour of RTCDataChannel.send which now raises TypeError in
case the message is too large for the other peer to receive. This is a
necessity to ensure that implementations that do not look at the EOR flag when
receiving are always able to receive our messages. Even if these
implementations do not set a=max-message-size, we use a safe default value (64
KiB, dictated by the spec) that every implementation should be able to receive,
with or without EOR support.
* Due to the use of explicit EOR, this required some major refactoring of all
send-related and deferred sending functions (which is now a lot less
complex). There's now only one place where `usrsctp_sendv` is being used.
* All data channel messages and DCEP messages will be sent without copying them
first. Only in case this fails (e.g. usrsctp's buffer is full), the message
will be copied and added to a buffer queue.
* Queued data channel messages will now be re-sent fairly (round-robin).
* Maximum message size and the PPID-based fragmentation are configurable using
about:config (media.peerconnection.sctp.force_ppid_fragmentation and
media.peerconnection.sctp.force_maximum_message_size).
* Enable interleaving of incoming messages for different streams (preparation
for SCTP ndata, has no effect until it is enabled).
* Enable interleaving of outgoing messages (disabled if SCTP ndata has not been
negotiated).
* Add pending messages flag to reduce performance impact from frequent calls to
SendDeferredMessages.
* Handle partial delivery events (for cases where a partially delivered message
is being aborted).
* Close a data channel/the connection in case the message is too large to be
handled (this is only applied in cases where the remote peer ignores our
announced local maximum message size).
* Various size_t to uint32_t conversions (message length) and back should be
safe now.
* Remove aUsingDtls/mUsingDtls from DataChannelConnection.
* Set maximum message size in SDP and in the data channel stack.
* Replace implicit NS_ENSURE_*'s with explicit NS_WARN_IF's.
* Add SetMaxMessageSize method for late-applying those signalling parameters
when a data channel has been created before the remote SDP was available.
* Limit remote maximum message size and add a GetMaxMessageSize method for a
future implementation of RTCSctpTransport.maxMessageSize.
MozReview-Commit-ID: FlmZrpC5zVI
--HG--
extra : rebase_source : 54e1b838c788a3abbded4fb32fe7c2788f8a9bc0
For Linux dev builds, change the developer build unpacked security check
exception to not depend on knowing the repo dir because MOZ_DEVELOPER_REPO
isn't reliably set whenever the firefox binary is run. Instead, make sure the
extension root directory is within NS_GRE_DIR. Use both checks on Mac.
MozReview-Commit-ID: IsbbNS58yf8
--HG--
extra : rebase_source : 64d1008a0513938edc111d12cb9fb28d2048ac82