Currently, FetchStreamReader never signals to the JS stream code that
the reader has been closed. This means that when a ServiceWorker
passes a ReadableStream to respondWith and the HTTP Channel gets
canceled, the JS code will keep generating the stream without ever
realizing the data's not going anywhere. It's necessary to cancel
the reader. Or do something like that, this seems to work!
--HG--
extra : rebase_source : 559af90ba766ebd4deb5d99b6696cd2207215f9f
In the scenario where a ServiceWorker returns a pass-through fetch via
`evt.respondWith(fetch("underlying"))`, in order for the "underlying"
HTTP channel to be canceled when the outer HTTP channel is canceled,
FetchDriver's OnDataAvailable method needs to return an error when
the output pipe experiences an error.
Unfortunately, the contract for ReadSegments is effectively that it
returns NS_OK regardless of what the rv of the write handler returned,
so relying on the returned rv is insufficient. And because various
Write*() methods will all fast-path to returning NS_OK if a count of 0
is passed, it's necessary to infer a closed/broken pipe by noticing
that we tried to write more than 0 bytes of data but 0 bytes were
written. (This is safe because the pipe we write into was created
by FetchDriver::OnStartRequest which explicitly creates an infinite
pipe, so it's not possible for the write to fail due to lack of space
in the pipe.)
--HG--
extra : rebase_source : 788dab679298841fc03bb054458b6f8cc4a0a8d9
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
/builds/worker/workspace/build/src/layout/xul/nsMenuFrame.cpp r=backout a=backout on a CLOSED TREE
--HG--
extra : amend_source : e09bf154093728898ad2c27dd185108f9ff3b009
We no longer call the function directly. It has been replaced by
nsStyleDisplay::GetTransitionCombinedDuraion(uint32_t).
MozReview-Commit-ID: 9wZExWPmnyG
--HG--
extra : rebase_source : dff6b4e686578e7c79e16148ab3ab63b40444be7
This is also a prerequisite to use repeated values for the used value.
Note that each count should never be zero since their initial value is 1 and
we never set zero length property value to the member.
MozReview-Commit-ID: 44ZMhopuK6o
--HG--
extra : rebase_source : 6284b2b5beb43bf78c16e0c39e95ec0e5118ed14
This is a prerequisite to use repeated values for the used value of the each
animation property instead of the computed values.
In a subsequent patch in this patch series, the timing function will be replaced
with the one which may be a repeated value in computed animation timing function values list.
MozReview-Commit-ID: GOKHE3MH0Ue
--HG--
extra : rebase_source : ecc270eddb648d2915292ec3e219f4e349c6047c
<!-- Please describe your changes on the following line: -->
https://bugzilla.mozilla.org/show_bug.cgi?id=1420928
Source-Repo: https://github.com/servo/servo
Source-Revision: 97e39797418486196e9685931e01a3d1b563f93e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b6829e2a84c8b6d7cd037d6b7cacd40769caca7b
