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