The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: L9UE3gXHG4Q
--HG--
extra : source : 37d74bf745b23542251cc6b021d6aabb5ffadea1
extra : intermediate-source : 0402b4bd34c293b44c76de22418899420c8e405b
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: H9I6vNDMdIr
--HG--
extra : rebase_source : cf537a1f65af003c6c4f8919b925b0f305c1dd4d
extra : source : 13b89ce4e6a66c840f82a335c71f5a12938aba22
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: DbTW5Bhd9E1
--HG--
extra : rebase_source : b27f666e5ca832d814fb6846208474e1ec66e5f4
extra : source : 9ff4e11402a9a43ed90298a9c354b0164cf9414f
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: F750v6NN81s
--HG--
extra : rebase_source : 714dd78df0f4c33e23e5b117615bd8fd561674c5
extra : source : 742bda9e6b1ddaf34d09894204ad18ce798b79b7
OnStartRequest callback chain is interrupted by add-on during the "http-on-modify-request" observer event.
Therefore, nsInputStreamPump think OnStartRequest is finished. After resuming http channel, nsHttpChannel
asynchronously continue the OnStartRequest procedure and synchronously resume the nsInputStreamPump. Before
nsDocumentOpenInfo invoke the next OnStartRequest on the listener chain, sync XHR in web content is executed
on the call stack. This will spin main thread event queue and will eventually callback OnDataAvailable/OnStopRequest
on the same call stack.
nsHttpChannel should not resume the nsInputStreamPump before |mCallOnResume| is complete, to ensure that
no input stream event can interrupt the resumed call stack before it finished.
MozReview-Commit-ID: 6Q9EtMhcff9
--HG--
extra : rebase_source : 5685bacd9fbc95207a2a1349a8db66d53e3cc524
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
Race only when we're going to read from the disk cache storage. Also skip racing if we're going to write to the offline cache, because we need the cache entry which would be ignored if network wins the race.
Fix circular dependency created when encountering a path to a nonexistent JAR
inner file.
Change cache JAR loads to not use ExtensionStreamGetter, instead call the JAR
channel's AsyncOpen2 method directly in the SimpleChannel callback.
Remove the code to handle cached JAR loads from ExtensionStreamGetter.
MozReview-Commit-ID: Kmry02eLYU1
--HG--
extra : rebase_source : 2d750b393b77e23f6ec4e20c322214611f5daea7
In child process, during shutdown, it's possible that IsNeckoChild() is true but gNeckoChild is null. When this case happens, we have to early return in RequestContext::DOMContentLoaded() to avoid the asseration failure (MOZ_ASSERT(!IsNeckoChild())) in RequestContext::ScheduleUnblock().
When a tail request is canceled, neither mCachePump nor mTransactionPump was created. That means we have to call AsyncAbort to make sure that OnStopRequest() will be called and the request will be removed from the load group.
RequestContextService will cancel all the blocked tail requests during xpcom-shutdown.
However, the timer for unblocking tail request might be already running.
RequestContext need to cancel the timer when all blocked tail request is canceled for that context.
MozReview-Commit-ID: 1Nbzu2a788w
--HG--
extra : rebase_source : 6a68310ab7984eb3ceebd089a1e36232b5f0a72b
I noticed a bug where the following can happen. The parent sends a
TrackCookiesLoad message followed by an HTTP OnStartRequest
message. When these messages are received in the child, the
TrackCookiesLoad message goes in the SystemGroup event queue and the
OnStartRequest message goes in the event queue for the relevant
tab. Unfortunately, this means that the OnStartRequest message could
run first since the queues have no guaranteed ordering.
We really should be putting the TrackCookiesLoad message in the same
queue that the OnStartRequest message goes in. I worked on that a
little bit, but it's hard to get right. For now, I would like to leave
the cookie message unlabeled. Any unlabeled message/event is totally
ordered with respect to all other messages/events, so this fixes the
bug.
MozReview-Commit-ID: KiLDAhlrbB8
Restrict the MRU cache for eTLD lookups to main thread only. This allows off
main thread lookups, but they will just take a slower path.
--HG--
extra : rebase_source : bb0676fc1be9dc6e02762a978b43765d79dcdfff
For some reason, triggering network directly from MaybeRaceCacheWithNetwork() causes performance regression of tp6_facebook tests. This patch changes it so that an event is posted instead.
The patch also adds network.http.rcwn.min_wait_before_racing_ms preference which can be used by users to avoid immediate racing.
Its return value is never used, and most implementations return nullptr anyway.
MozReview-Commit-ID: 8rxC053mmE8
--HG--
extra : rebase_source : 61a0b8b1373396182efd27d3c01b96e5e5541364
The WebRequest API needs to know if a given window ID is at the top level, for
various reasons. It currently figures this out by mapping a channel's load
context to a <browser> element, which tracks its current top outer window ID.
But this is inefficient, and not friendly to C++ callers.
Adding the top window ID to the load info simplifies things considerably.
MozReview-Commit-ID: Fy0gxTqQZMZ
--HG--
extra : rebase_source : bb5b1e1b3294004ca5e713fc88c4e20652296e53
These methods return an addrefed raw pointer, which makes them easy to use in
ways that cause leaks. If they're to continue returning an addrefed pointer,
they should explicitly return an already_AddRefed.
This also switches to StaticRefPtr with ClearOnShutdown for the cached
pointers for the sake of sanity.
MozReview-Commit-ID: D0lDpU8Hqug
--HG--
extra : rebase_source : 7b199070805fc0472eaf8409932517700ed23d49
Fix ExtensionProtocolHandler::GetAsync() to handle failures returned
from AsyncOpen2() for cached JAR resources.
Don't call SetupEventTarget() in the cached JAR ExtensionStreamGetter
constructor because the event target is not needed and calling
SetupEventTarget() triggers a debug mode warning from
nsContentUtils::GetEventTargetByLoadInfo().
MozReview-Commit-ID: KjDsPNQWlwU
--HG--
extra : rebase_source : d44e8a1cdf358f364156a3dc2ac6a428b57d5e32
This patch calls CancelTailPendingRequests(NS_ERROR_ABORT) for every RequestContext at shutdown, then prevents the creation of any more RequestContexts.
MozReview-Commit-ID: BbJDL7Np8HW
--HG--
extra : rebase_source : d144e3b09d9725fbc7df169f1c9a49bf45ddfd54
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
This allows MOZ_TRY and MOZ_TRY_VAR to be transparently used in XPCOM methods
when compatible Result types are used.
Also removes a compatibility macro in SimpleChannel.cpp, and an identical
specialization in AddonManagerStartup, which are no longer necessary after
this change.
MozReview-Commit-ID: 94iNrPDJEnN
--HG--
extra : rebase_source : 24ad4a54cbd170eb04ded21794530e56b1dfbd82
This edits the third party SCTP library, but upstream has already applied this change to master
MozReview-Commit-ID: ERpMc8EvYZ7
--HG--
extra : rebase_source : cea0d3758275b73a395ad2738edd8eb57c833e1a
This moves URI creation from ParseMetaDataEntry into SetupPrediction
because ParseMetaDataEntry is called in way more circumstances than we
actually need the URI from. Even in those cases where we might use the
URI (but it's not guaranteed), we end up using the URI less often than
we create one. In case it wasn't clear, SetupPrediction is the only
thing called post-ParseMetaDataEntry that would require a parsed URI in
the first place.
SetupPrediction has the duplicated NS_NewURI calls to avoid creating
URIs for those calls to SetupPrediction that are no-ops.
MozReview-Commit-ID: HlhVj7p2uuk
--HG--
extra : rebase_source : 0349dc52225b6e93150947ea978f2ba7afa3e2f5
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
These are all straightforward except for InternalLoadEvent::mTypeHint, which
requires a bit of care to preserve existing behaviour.
--HG--
extra : rebase_source : 9b152122b011cf49b9acccdc98b4693548b8bdd2
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
NS_AsyncCopy aborts if it receives an NS_BASE_STREAM_WOULD_BLOCK error result
during copying and it is unable to QI the source stream to an
nsIAsyncInputStream. IPCBlobInputStream can return this, especially if it's:
- A freshly created aggregate stream as part of form submission of a type=file
where the Blob will come from the parent because of the file picker but the
stream is being uploaded from the child.
- A ServiceWorker is involved, causing
HttpBaseChannel::EnsureUploadStreamIsCloneable to trigger an NS_AsyncCopy
very early in the process.
IPCBlobInputStream implements nsIAsyncInputStream, and nsMultiplexInputStream
does too (conditionally based on its child streams; if any are async, it takes
step to uniformly expose async behavior). However, due to lack of sufficient
test coverage, nsMIMEInputStream did not get fixed as part of bug 1361443 when
nsMultiplexInputStream gained its nsIAsyncInputStream powers. We address that
here in the same fashion.
Part 1 of this series addresses the test coverage issue.
--HG--
extra : rebase_source : 1cae03a314397b159c3985d97231c1e34cd5f079
This patch is mainly to add a probe to measure sw launch time. To do this, this
patch records the sw launch time when the sw is just spwaned and it's ready to
handle the incoming fetch event.
MozReview-Commit-ID: 3w5MNyhQNnd
--HG--
extra : rebase_source : 3228213d0ea6be1d23b9c49382f1f8d3c2f358f1
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is null checked. The patch uses IsVoid() to replace
the null checks (and get() and EqualsLiteral() calls to replace any implicit
conversions).
--HG--
extra : rebase_source : 484ad42a7816b34b86afbe072e04ba131c1619c6
Most of these fields are not using any nsXPIDLCString-specific features.
The exceptions are mUserAgentOverride and mDefaultSocketType, which require a
little more care.
--HG--
extra : rebase_source : 50d2178b7bf10f6076fe27f2e65a4b63f1153590
The existing functions work with C strings but almost all the call sites use
Mozilla strings.
The replacement function has the following properties.
- It works with Mozilla strings, which makes it much simpler and also improves
the call sites.
- It appends to the destination string because that's what a lot of the call
sites need. For those that don't, we can just append to an empty string.
- It is declared outside the |extern "C"| section because there is no need for
it to be in that section.
Note: there is no 16-bit variant of nsAppendEscapedHTML(). This is because
there are only two places that need 16-bit variants, both rarely executed,
and so converting to and from 8-bit is good enough.
The patch also adds some testing of the new function, renaming
TestEscapeURL.cpp as TestEscape.cpp in the process, because that file is now
testing other kinds of escaping.
--HG--
rename : xpcom/tests/gtest/TestEscapeURL.cpp => xpcom/tests/gtest/TestEscape.cpp
extra : rebase_source : 51145ae2c9b0b4573c7ea0c342dcb246f9f14fb9
This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
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
- Use displayPrePath in the pageInfo permissions that shows "Permissions for:"
- The extra displayPrePath method is necessary because it's difficult to compute it manually, as opposed to not having a displaySpecWithoutRef - as it's easy to get that by truncating displaySpec at the first '#' symbol.
MozReview-Commit-ID: 9RM5kQ2OqfC
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is used in ways that rely on the implicit conversion
to |char*|. The patch uses get() and EqualsLiteral() calls to replace the
implicit conversions.
This adds a most recently used (MRU) cache for the most common base domain
requests (aAddtionalParts == 1). With a table size of 31 I saw 8777 hits and
22 misses when loading twitter, youtube, and techcrunch. In stress testing
this provided a 75% reduction in run time.
MozReview-Commit-ID: 3JgCwIZagMs
Sebastian Hengst
Amy Chung
Chris Peterson
Shih-Chiang Chien
Thomas Nguyen
Valentin Gosu
Jonathan Kew
Dragana Damjanovic
Wes Kocher
Kershaw Chang
Kris Maglione
Joel Maher
Andrea Marchesini
Boris Zbarsky
Ryan VanderMeulen
Jeff Gilbert
Michal Novotny
haftandilian@mozilla.com
Bill McCloskey
Eric Rahm
Honza Bambas
Nicholas Hurley
Andrew McCreight
Gerald Squelart
Ionut Goldan
Ethan
Christoph Kerschbaumer
Liang-Heng Chen
Henri Sivonen
Sajjad Arshad
Tom Ritter
Jan de Mooij
Nicholas Nethercote
Andrew Sutherland
Tom Tung
Chung-Sheng Fu
Phil Ringnalda
Shane Caraveo
Michael Kaply
Carsten "Tomcat" Book
Masatoshi Kimura
Dragana Damjanovic dd.mozilla@gmail.com
Jim Blandy
Junior Hsu
Lennart Grahl
Thomas Wisniewski
Sylvestre Ledru
Michael Layzell