There are some corner cases where we try to attach StreamFilter endpoints to a
channel after its IPC has been closed from from the other side, but request
listeners haven't been notified. This causes crashes in any of several places.
This patch changes nsHttpChannel::ProcessId to return 0 when IPC is closed, so
callers can detect that it's no longer possible to attach endpoints to it.
MozReview-Commit-ID: BZTOqezih0P
--HG--
extra : rebase_source : dfdb5bf7a11fccea51a1fbb161e688f10167da30
This is a follow-up to bug 1409249. There are a lot of places where our
factory singleton constructors either don't correctly handle their returned
references being released by the component manager, or do handle it, but in
ways that are not obvious.
This patch handles a few places where we can sometimes wind up with dangling
singleton pointers, adds some explanatory comments and sanity check
assertions, and replaces some uses of manual refcounting with StaticRefPtr and
ClearOnShutdown.
There are still some places where we may wind up with odd behavior if the
first QI for a getService call fails. In those cases, we wind up destroying
the first instance of a service that we create, and re-creating a new one
later.
MozReview-Commit-ID: ANYndvd7aZx
--HG--
extra : rebase_source : acfb0611a028fef6b9387eb5d1d9e285782fbc7c
The SyntheticDiversionListener needs to handle the case where the IPC
connection is gone. This patch avoids calling Send* methods which will
crash the content process if the actor has already been destroyed.
Additionally, OnDataAvailable will return an error in such a case so
that the caller can properly handle the error rather than continuing to
attempt to send data to a listener that doesn't care. This latter
change is an artifact of a previous hack attempt to fix a related
diversion issue that is probably not required for this stack, but makes
sense as a fix, so I've left it in.
--HG--
extra : rebase_source : 44ee7941be7619a8532c5194eca88fb0ca6323f7
extra : source : 5453b8a58f0c2c28dc7c407c531c266972bff423
The diversion mechanism never expected to be dealing with data sourced
from the content process, but that's exactly what happens with
ServiceWorker-intercepted channels with the current child-intercept
situation (which is being fixed).
In order to allow timely cancellation of diverted intercepted
channels, there needs to be a way to relay to the HttpChannelChild
that it needs to be canceled so that the synthesized pump can be
canceled and diversion can be marked as complete. This patch adds
such a mechanism to ADivertableParentChannel and PHttpChannel for the
exclusive use of InterceptedHttpChannel and then uses it.
--HG--
extra : rebase_source : db71e927bd1837c6a67f6d56df52cfbb7294df73
extra : source : d156f6b687e1cd8717bf813ab1b944e87b67ed5d
Diversion for intercepted channels with a synthesized response is a
special case. It is not appropriate to send DivertComplete when
mEventQ has been drained, because we are not dealing with the usual
mEventQ-enqueued OnDataAvailable payloads that had been received over
the network and sent down to the child. In this case, all the data
originates in the child and does not go through mEventQ. As such,
the correct place to send DivertComplete is at OnStopComplete for the
synthesized response.
--HG--
extra : rebase_source : a4e1593d38629173b829014a3c316ad156094580
extra : source : 714d3942fb10a96e60e14c475e24e640b9ddd8cc
This also fixes the bug that prevented throttled http/2 streams from
ever re-starting by calling TransactionHasDataToRecv.
MozReview-Commit-ID: 5dFotZGhQk9
--HG--
extra : rebase_source : 2ba35bef4e17d90fc2abe52958bb6459b052b7e7
STS header checking was happening before http-on-examine-response which prevents
an observer from adding the STS headers to enforce STS. This moves the header
processing to after the notification occurs. In a webextension,
WebRequest.onHeadersReceived can now be used to inject STS and have that
recognized by HttpChannel.
MozReview-Commit-ID: KYZCSTBnZL7
--HG--
extra : rebase_source : 7a36fab9361e1da0223a4e63fe770228ea99538f
* Converts PLDHashTable mDB to nsRefPtrHashtable<nsGenericHashKey<nsHostKey>, nsHostRecord> mRecordDB
* Removes nsHostDBEnt and associated PLDHashTableOps
This patch makes the code a lot easier to understand, by simplifying the
ownership model. Now the hashtable holds RefPtr<nsHostRecord>, so it's
easier to follow the lifetime of each record.
MozReview-Commit-ID: IMavN8YSPSn
--HG--
extra : rebase_source : 3ff3135e2d9610577f15aaf307a62eec5ed3b47a
This issue is triggered by off-main-thread ODA listener that return error cause from OnDataAvailable callback.
A CancelEvent will be prepend to event queue and trigger race condition between CompleteResume and EndForceEnqueueing.
The `mFlushing` is checked and set in separate critical sections, therefore two threads that executing MayFlushQueue
might both pass the `mFlushing` check and trying to call FlushQueue simultaneously.
The solution is to check and set `mFlushing` in single critical section, so we can guarantee that only one FlushQueue
can be executed at anytime.
In addition, resumption is postponed until no AutoEventEnqueuer is activated. Therefore, CompleteResume will only be
triggered while all the suspension requests and auto enqueue requests are finished.
MozReview-Commit-ID: HpxzgUqYm8C
--HG--
extra : rebase_source : 9be0d37bb4475a0817dafb6270585263160a9da1
The SyntheticDiversionListener needs to handle the case where the IPC
connection is gone. This patch avoids calling Send* methods which will
crash the content process if the actor has already been destroyed.
Additionally, OnDataAvailable will return an error in such a case so
that the caller can properly handle the error rather than continuing to
attempt to send data to a listener that doesn't care. This latter
change is an artifact of a previous hack attempt to fix a related
diversion issue that is probably not required for this stack, but makes
sense as a fix, so I've left it in.
--HG--
extra : rebase_source : 824d4ab64e92ebb04d8d1ecd4df6d03a2cb37d2f
The diversion mechanism never expected to be dealing with data sourced
from the content process, but that's exactly what happens with
ServiceWorker-intercepted channels with the current child-intercept
situation (which is being fixed).
In order to allow timely cancellation of diverted intercepted
channels, there needs to be a way to relay to the HttpChannelChild
that it needs to be canceled so that the synthesized pump can be
canceled and diversion can be marked as complete. This patch adds
such a mechanism to ADivertableParentChannel and PHttpChannel for the
exclusive use of InterceptedHttpChannel and then uses it.
--HG--
extra : rebase_source : 59d3aa5e541d2a404c6320ae9fce03e7c9cd8b81
Diversion for intercepted channels with a synthesized response is a
special case. It is not appropriate to send DivertComplete when
mEventQ has been drained, because we are not dealing with the usual
mEventQ-enqueued OnDataAvailable payloads that had been received over
the network and sent down to the child. In this case, all the data
originates in the child and does not go through mEventQ. As such,
the correct place to send DivertComplete is at OnStopComplete for the
synthesized response.
--HG--
extra : rebase_source : 2209c25ad6f2b5655728d8dc07ef7f8b64df6ea6
Calling SetSpec on an nsIURI object doesn't reinitialize the object, meaning
it's not equivalent with creating a new URI with the same spec. While this
might be counter-intuitive we want to preserve existing behaviour for
the moment.
This change makes BaseURIMutator::InitFromSpec call SetSpec on the existing
cloned URI if available. Otherwise it creates a new one.
MozReview-Commit-ID: LuHVRhBItiP
--HG--
extra : rebase_source : fc7b64d01adcb7f2ac5bbd9cfc16dadb3c4939c9
